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

Question

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

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

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

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

Answer 1

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

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

Answer 2

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

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

Answer 3

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

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

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

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