Какой из способов организации хранения адресов и данных паспорта выбрать?

Question

[Евгений]

Доброго времени суток, уважаемые пользователи.
Возник вопрос, как организовать хранение адресов и паспортных пользователей в БД.
На данный момент, адреса хранятся в виде массива и пишутся в json поле в базе данных все сразу

addresses: {
                        isAddressSimilar: false, //Адрес регистрации совпадает с адресом проживания
                        isAddressPlaceOfStay: false, //Адрес регистрации совпадает с адресом регистрации по месту пребывания
                        registration: {//Адрес регистрации
                            area: null,
                            city: null,
                            index: null,
                            region: null,
                            street: null,
                            housing: null,
                            settlement: null,
                            house_number: null,
                            apartment_number: null
                        },
                        residential: {//Адрес проживания
                            area: null,
                            city: null,
                            index: null,
                            region: null,
                            street: null,
                            housing: null,
                            settlement: null,
                            house_number: null,
                            apartment_number: null
                        },
                        place_of_stay: {//Адрес регистрации по месту пребывания
                            area: null,
                            city: null,
                            index: null,
                            region: null,
                            street: null,
                            housing: null,
                            settlement: null,
                            house_number: null,
                            apartment_number: null
                        },
                    },

С данными паспорта такая же история

passport: {
                        nationality: 'russia',
                        documentType: 'RfPassport',
                        series: null,
                        number: null,
                        issuanceDate: DateTime.local().toISODate(),
                        subdivisionCode: null,
                        issued: null,
                        birthPlace: null,
                    },

Вопрос, правильно ли будет хранить данные в виде json массива в таблице пользователей или имеет смысл заводить отдельные таблицы, где каждое поле, это отдельное поле из массива и через связи подтягивать данные?

Заранее спасибо

Answer 1

[Павел Чесноков]

Вероятнее всего, что вид хранения полностью зависит от нескольких факторов:

• Количество и структура информации влияет на выбор типа базы данных (реляционной или нереляционной). В вашем случае (json массив и миллион паспортов) = надо смотреть в сторону NoSQL и хранить всё одним блоком (коллекцией) ради мифической скорости. Но ведь больше не будет ветвиться структура и не появятся новые зависимости, количество полей известно и очень легко и красиво делиться на таблички.
  
• Паспортные данные = личная информация = надо её защищать, любить и лелеять. GDPR дойдёт и до вас, не сомневайтесь. И тогда: разборки, анальные досмотры, суды, штрафы и т.д. И когда вашу базу кто-то стащит он не должен получить всю информацию в явном виде, т.е. такие данные должны храниться частями в разных местах: имена отдельно, адреса отдельно, мухи отдельно. Снова смотрим в сторону табличек, параллельно раскладывая данные разных таблиц на разных серверах и в разных ЦОД'ах.
  
• Кто заказчик? Вы делаете это для себя? Для турагентства? Для ФСБ? Для себя - вообще неважно, что, как и где хранить, главное чтоб вам было интересно код писать. Для турагентства - скоро им запретят хранить такую информацию и вам дадут заказ всё переделать по новым законам/правилам/СНиП'ам. А вот ФСБ сами скажут (или ночью подправят ваш код) какая структура данных должна быть и как её хранить по ГОСТ'у.
  

По моему мнению, с учётом вышеизложенного, информацию такого типа надо дробить на мелкие кусочки и складывать в отдельные таблички. И пускай меня засмеют проповедники обречённости реляционных моделей - я упёртый консерватор.

Comments

[Евгений]

Благодарю за развернутый ответ. Заказчик - образовательная организация среднего профессионального образования, так что подобный механизм хранения данных нужен будет не только для студентов, но и для сотрудников и абитуриентов.

[Павел Чесноков]

Евгений, Если мой ответ вас полностью устраивает, то не забудьте его отметить как "решение".

Answer 2

[Игорь Воротнёв]

Павел Чесноков дело говорит, а по сути:
- User hasOne Passport / Passport belongsTo User (связь OneToOne)
С адресами чуток сложнее, тут я бы сами адреса хранил отдельно через связь OneToMany, с дополнительным свойством type. А вот isAddressSimilar и isAddressPlaceOfStay - либо флагами в User, либо вообще динамическим свойством - например если записи адреса с типом place_of_stay не существует, то юзаем дефолтный (registration) или просто возвращаем false. Ибо хранить записи где все колонки кроме PK null это не ок.

Comments

[Boris Köln]

Человек имеет за жизнь как минимум 3 паспорта (по очереди), в реальности (из-за смены фамилии, утери и пр.) - больше

[Игорь Воротнёв]

Boris Korobkov, нет, в одно время человек имеет 1 паспорт (или по 1му паспорту разных типов - внутренний и загран, в некоторых странах). В случае замены происходит именно ЗАМЕНА, старый паспорт теряет свою актуальность и по хорошему должен быть заменен в БД на новый. Хранить неактуальные паспорта нет необходимости если только вы не паспортный стол. В вопросе нету конкретного требования хранить несколько паспортов, такое допущение может только выплывать из наличия свойства documentType. В этом случае, если ваше предположение верно, то связь будет oneToMany конечно же.

[Евгений]

Игорь Воротнёв, в нашем случае это не только паспорт РФ, а документ удостоверяющий личность, который подают сотрудники или студенты, будь то военный билет, свидетельство о рождении, загранник и.т.д. Просто в подавляющем большинстве подают паспорта РФ, и предыдущий разработчик так назвал поля

[Игорь Воротнёв]

Евгений, а, ну тогда однозначно oneToMany, да еще и над названиями полей надо подумать хорошенько.