1. User
1.1. id
1.2. password
1.3. password_confirmation
1.4. email
1.5. user_identification_key?
1.5.1. это про безопасность транзакций запросов итд. будет копироваться в другие таблицы запросов как цифровая подпись. почему бы и не да.
1.6. INT_presence
1.7. contact_info
1.7.1. место прибывания и прочее.
1.8. user_info_id
1.8.1. Entities_user
1.8.1.1. id
1.8.1.2. user_id
1.8.1.3. Users_list
1.8.1.3.1. id
1.8.1.3.2. user_id
1.8.1.4. что вообще может юр-лицо? кроме как вести пользователей?
1.8.2. Individuals_user
1.8.2.1. если пользователь может иметь много патентов к примеру, то я убираю patent_id и подклчаю патент к пользователю а не пользователя к патенту.
1.8.2.2. id
1.8.2.3. user_id
1.8.2.4. documents_list
1.8.2.4.1. passport_id
1.8.2.4.2. patent_id
1.8.2.4.3. migration_map_id
2. Passport
2.1. id
2.2. number
2.3. series
2.4. name
2.5. surname
2.6. patronymic
2.7. sex
2.8. birthday
2.9. place_of_birth
2.9.1. хе хе.. просто текстом или ещё будем подключать локацию и базу городов?
2.10. date_of_issue
2.11. issued_by
2.12. unit_code
2.13. additional_passport_info
2.13.1. Registration_info
2.13.1.1. а так же семейное положение и прочее я думаю вынести в отдельную таблицу с belongs_to
2.13.2. marital_status
3. Patent
3.1. id
3.2. user_id
3.3. какие данные должны быть в патенте?
4. Claim
4.1. id
4.2. type
4.2.1. ITN_receiving_claim
4.2.1.1. что должно быть в заявке?
4.2.2. Patent_reissuance_claim
4.2.2.1. что должно быть в заявке?
4.2.3. Patent_receiving_claim
4.2.3.1. что должно быть в заявке?
4.2.4. MVD_claim
4.2.4.1. запрос на действительность в МВД. какие данные туда отправлять?
4.2.5. pay_claim
4.2.5.1. id
4.2.5.2. amount
4.2.5.3. user_identification_key?
4.2.5.4. pay_info
4.2.5.4.1. электронный чек, номер или любые данные что отдают кассы
4.2.5.5. это запрос на оплату он сохраниться в базе и перенаправит на кассу оплаты. а потом сохранит данные об оплате.
4.2.5.6. подписка на оплату. происходит на сервисе оплаты. и так же надо будет придумать как это оформить у нас.