Когда разделить модели на несколько таблиц базы данных?
Я работаю с Ruby on Rails, но этот вопрос, я думаю, более широк, чем это и обычно относится к проектированию баз данных.
Когда это - хорошая идея разделить единственную модель на несколько таблиц? Например, предположите, что у меня есть модель User, и количество полей в модели действительно начинает складывать. Например, Пользователь может ввести свой веб-сайт, свой день рождения, свой часовой пояс, его и т.д. и т.д.
Есть ли какое-либо преимущество или недостаток к разделению модели, такой, что, возможно, таблица User только имеет основную информацию как вход в систему и электронная почта, и затем существует другая таблица, которую каждый Пользователь имеет, который похож на что-то UserInfo, и другой, который является UserPermissions и другой, который является UserPrivacySettings или чем-то как этот?
Править: Для добавления дополнительного блеска на этом к большинству полей редко получают доступ, за исключением страниц, характерных для них. Например, к вещам как день рождения только когда-либо получают доступ, если кто-то нажимает до профиля Пользователя. Кроме того, некоторые поля (к которым редко получают доступ) имеют потенциал, чтобы быть чрезвычайно большими. Большинство полей имеет потенциал, который будет или установлен очистить или ноль.
3 ответа
Получение строки обходится дороже, если в ней много столбцов, особенно если обычно требуется только несколько полей. Кроме того, хостинг, такой как компоненты адреса в отдельном классе, является случаем DRY. С другой стороны, если требуются все поля объекта, выполнение составного запроса занимает больше времени.
Обычно я бы не удосужился распределить классы по нескольким таблицам, чтобы сделать код более читаемым (то есть без фактически многократно используемых частей, таких как адреса).
-121--1858860-Как правило, это хорошая идея поместить вещи, которые имеют отношения один к одному в одной таблице. Если ваш userbase включает Queen или Paddington Bear, пользователь имеет только один день рождения, так что это должно быть атрибутом таблицы USERS. Вещи, которые имеют отношение «один ко многим», должны быть в отдельных таблицах. Таким образом, если пользователь может иметь несколько настроек частной жизни всеми способами разделить их.
Разделение одной таблицы на несколько таблиц может усложнить или замедлить выполнение запросов, если требуется получить всю информацию пользователя одновременно. С другой стороны, если у нас есть набор атрибутов, которые только когда-либо запрашиваются или обновляются дискретным образом, то наличие отдельной таблицы для хранения этих данных является здравой идеей.
Это ситуация для анализа.
Когда вы обнаружите, что многие поля в такой таблице имеют значение NULL и могут быть сгруппированы вместе (например, UserContactInfo) , пора взглянуть на извлечение информации в отдельную таблицу.
Вы хотите избежать таблицы с десятками или сотнями полей с редко вводимыми данными.
Скорее попытайтесь сгруппировать данные логически и создать основную таблицу, содержащую поля, которые в основном все заполнены. Затем вы можете создавать подмножества данных, почти так же, как вы представляете их в пользовательском интерфейсе (контактная информация, личные интересы, информация, связанная с работой и т. Д.), В отдельные таблицы.
Получение строки обходится дороже, если в ней много столбцов, особенно если вам обычно нужны только некоторые поля. Кроме того, размещение таких вещей, как компоненты адреса, в отдельном классе - это случай DRY. С другой стороны, если вам нужны все поля объекта, выполнение составного запроса займет больше времени.
Обычно я бы не стал распределять классы по нескольким таблицам только для того, чтобы сделать код более читабельным (т.е. без фактически повторно используемых частей, таких как адреса).