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

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

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

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

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

Ответ 1

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

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

Ответ 2

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

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

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

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

Ответ 3

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

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