Почему стол с большим количеством столбцов пахнет?

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

Позвольте мне взять пример users Таблица.

Пользователь может иметь first_name, last_name, street_name, city, state, age, так далее. Согласно аргументу, я предполагаю street_name, city а также state должны быть перемещены в другую таблицу. Я согласен с тем, что связанные данные сгруппированы таким образом, но если приложение запрашивает также пользователя с его адресом, не будет ли это более дорогой операцией, поскольку теперь они находятся в 2 таблицах?

Итак, как правильно моделировать таблицы с большим количеством атрибутов? (Должны ли мы также рассмотреть эти случаи: когда 1. количество строк будет меньше 2. количество строк будет огромным)

Источник

3 ответа

Решение

Используя ваш address В частности, в этом сценарии вы найдете очень полезным, если ваш дизайн должен обслуживать несколько адресов на пользователя или отслеживать / перехватывать несколько регистраций, используя один и тот же адрес.

В качестве альтернативы, вы могли бы рассмотреть более общую реализацию таблицы адресов, где у вас есть общий description поле и type столбец, который помечает строку как адрес определенного типа (например, email, house, office, spouse, так далее.).

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

  1. Не сильно меняется,
  2. Не встречается более одного раза или
  3. Каждый объект первичного ключа должен иметь его.
Источник

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

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

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

Источник

Это довольно академический вопрос. При разработке модели базы данных вы часто имеете в виду только одну вещь: производительность. Вы не разделите стол только потому, что он выглядит лучше. Вы будете делать это, например,

  • когда вы можете уменьшить избыточность
  • или повысить параллелизм.

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

Это совершенно другое при разработке классов. Разделение классов не оказывает большого влияния на производительность, но оказывает большое влияние на обслуживание. Ремонтопригодность должна быть главной заботой.

Источник
Другие вопросы по тегам