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

Question

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

Answer 3

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

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