Это хорошая идея для проектирования базы данных с наследованием?

Question

Например, у меня есть 2 таблицы: «клиент» и «персонал».Они почти одинаковые, только 2 атрибута разные.Так стоит ли мне создавать другую таблицу с именем person, содержащую все те же атрибуты customer и staff, а затем создавать ключи fk, указывающие на этого person?Что-то вроде наследования в дизайне класса.

Есть ли какой-либо недостаток у этого метода?

Answer 1

Да, у этого метода есть недостаток. Объединения увеличивают сложность запроса (в некоторых случаях очень сильно) и могут увеличить время запроса, если вы не будете осторожны.

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

Это работает так: вы создаете одну таблицу, которая содержит все атрибуты, в том числе атрибуты, которые применяются только к одному или другому, а также атрибут type для указания типа объекта. Например, если customer имеет атрибуты:

id, name, email, password, order_date

AND staff имеет атрибуты:

id, name, email, password, hire_date

Затем вы создаете одну таблицу со столбцами для всех атрибутов и типа:

id, type, name, email, password, order_date, hire_date

В столбце type всегда указывается либо «клиент», либо «персонал». Если type является «клиентом», то hire_date всегда равно NULL и не имеет смысла. Если type означает «персонал», то order_date всегда равно NULL и не имеет смысла.

Answer 2

Вы описываете шаблонный вызов Наследование таблицы классов . Это действительный дизайн, но, как и любой другой дизайн, его следует использовать с разумной оценкой. Прочтите «Шаблоны архитектуры корпоративных приложений» Мартина Фаулера, чтобы узнать больше о ее преимуществах и недостатках.

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

Answer 3

И Пранай Рана, и Бен Ли верны, и окончательный ответ таков: «это зависит».

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

В таком случае, как вы собираетесь относиться к персоналу, который также является клиентом?

Answer 4

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

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

Это заставляет специализированные идентификаторы выполнять двойную функцию.Они являются как pk, так и fk ссылкой на соответствующую строку в обобщенной таблице.Это упрощает и ускоряет объединения.

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

Answer 5

Ну, я говорю, что это хороший дизайн, потому что вы не повторяете данные, и это при нормализации данных.

только одна вещь - это то, что если вы нормализуете, ваше количество не увеличится.