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

Я работаю с Ruby on Rails, но я думаю, что этот вопрос шире и применим к дизайну базы данных в целом.

В каких случаях целесообразно разделить одну модель на несколько таблиц? Например, предположим, что у меня есть модель User, и количество полей в модели действительно начинает увеличиваться. Например, Пользователь может ввести свой веб-сайт, свой день рождения, свой часовой пояс, свой и т. д. и т. д.

Есть ли какое-либо преимущество или недостаток в разделении модели, например, что, возможно, таблица User содержит только базовую информацию, такую ​​как логин и адрес электронной почты, а затем есть еще одна таблица, которая есть у каждого пользователя, что-то вроде UserInfo, а другая - UserPermissions, и другой, это UserPrivacySettings или что-то в этом роде?

Редактировать: чтобы добавить дополнительный блеск, к большинству полей редко обращаются, за исключением страниц, специфичных для них. Например, такие вещи, как день рождения, доступны только в том случае, если кто-то переходит в профиль пользователя. Кроме того, некоторые поля (к которым редко обращаются) могут быть чрезвычайно большими. Большинство полей могут быть либо пустыми, либо нулевыми.


database database-design models
person William Jones    schedule 16.02.2010    source источник
comment
О скольких полях мы фактически говорим в таблице User?   -  person brettkelly    schedule 16.02.2010

Ответы (3)


arrow_upward
9
arrow_downward

Как правило, хорошей идеей является размещение в одной таблице вещей, которые имеют отношение один к одному. Если ваша пользовательская база не включает Королеву или Медведя Паддингтона, у пользователя есть только один день рождения, так что это должно быть атрибутом таблицы USERS. Вещи, которые имеют отношения «один ко многим», должны быть в отдельных таблицах. Итак, если у пользователя может быть несколько настроек конфиденциальности, обязательно разделите их.

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

person APC    schedule 16.02.2010

arrow_upward
3
arrow_downward

Это будет ситуация для анализа.

Когда вы обнаружите, что многие поля в такой таблице имеют значение NULL и могут быть сгруппированы вместе (например, UserContactInfo), пришло время рассмотреть возможность извлечения информации в собственную таблицу.

Вы хотите избежать таблицы с десятками/сотнями полей с редко введенными данными.

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

person Adriaan Stander    schedule 16.02.2010
comment
Каковы недостатки, связанные с таблицей с редко введенными данными? - person William Jones; 16.02.2010

arrow_upward
3
arrow_downward

Извлечение строки обходится дороже, если в ней много столбцов, особенно если вам обычно нужны только некоторые поля. Кроме того, размещение таких вещей, как компоненты адреса в отдельном классе, является случаем DRY. С другой стороны, если вам нужны все поля объекта, выполнение составного запроса займет больше времени.

Обычно я бы не стал распределять классы по нескольким таблицам только для того, чтобы сделать код более читабельным (т.е. без фактически повторно используемых частей, таких как адреса).

person Kilian Foth    schedule 16.02.2010
comment
Кроме того, будет ли дороже извлекать строку с большим количеством столбцов, когда вы выбираете только те столбцы, которые необходимы? Или это будет выполняться за то же время, как если бы было меньше столбцов. - person Steven Ryssaert; 22.04.2015