Дизайн базы данных для отношений один-к-одному

Question

Я пытаюсь доработать свой дизайн модели данных для своего проекта, и мне сложно понять, как с ним работать.

У меня есть таблица пользователей и неопределенное количество атрибутов, которые применяются к этому пользователю. Атрибуты почти во всех случаях являются необязательными, поэтому допускаются нулевые значения. Каждый из этих атрибутов индивидуален для пользователя. Должен ли я поместить их в одну и ту же таблицу и продолжать добавлять столбцы при добавлении атрибутов (что делает таблицу пользователей достаточно широкой), или я должен поместить каждый атрибут в отдельную таблицу с внешним ключом для таблицы пользователей.

Я решил не использовать модель EAV.

Спасибо!

Редактировать

Свойства включают в себя такие вещи, как семейное положение, пол, возраст, имя и фамилия, род занятий и т. Д. Все являются необязательными.

Answer 1

Таблица:

• ПОЛЬЗОВАТЕЛИ
• USER_PREFERENCE_TYPE_CODES
• USER_PREFERENCES

USER_PREFERENCES - это таблица «многие ко многим», соединяющая таблицы USERS и USER_PREFERENCE_TYPE_CODES. Это позволит вам нормализовать атрибут типа предпочтения, в то же время сохраняя гибкость в добавлении предпочтений без использования оператора ALTER TABLE.

Answer 2

Лично я бы решил, есть ли естественные группировки атрибутов. Вы можете поместить наиболее часто запрашиваемые в пользовательской таблице, а остальные - в отдельную таблицу с отношением один к одному, чтобы таблица не была слишком широкой (мы обычно называем это что-то вроде User_Extended). Если некоторые атрибуты попадают в естественные группировки, они могут вызывать отдельную таблицу, потому что эти атрибуты обычно запрашиваются вместе.

Рассматривая атрибуты, изучите, могут ли некоторые быть объединены в один столбец (например, если пользователь не может simlutaneoulsy быть тремя разными вещами (скажем, стажер, резидент, присутствующий), но только один из них за раз, лучше иметь одно поле и помещать в него данные, а не три битовых поля, которые необходимо перевести. Это особенно верно, если вам нужно использовать оператор case со всеми тремя полями для получения необходимой информации (скажем, заголовка) в составление отчетов. Другими словами, просмотрите ваши атрибуты и посмотрите, являются ли они действительно отдельными или могут ли они быть абстрагированы в более общий.

Answer 3

Это зависит.

Вам нужно посмотреть, какой процент пользователей будет иметь этот атрибут. Если атрибут «WalkedOnTheMoon», то выделите его, если «Пол», включите его в таблицу пользователя. Также рассмотрите количество столбцов в базовой таблице, несколько, 10-20, не повредит так много.

Если у вас есть несколько связанных атрибутов, вы можете сгруппировать их в общую таблицу: «MedicalSchoolId», «MedicalSpeciality», «ResidencyHospitalId» и т. Д. Можно объединить в таблицу UserMedical.

Answer 4

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

Как бы то ни было, одним из способов было бы разделить данные:

Одна таблица (пользователи) для имени пользователя, hashed_password, last_login, last_ip, current_ip и т. Д., Другая таблица (профили) для отображения имени, дня рождения и т. Д.

Вы бы связали их либо через то же свойство id, либо добавили бы столбец user_id в другие таблицы.