Есть ли у этих стилей проектирования баз данных (или антишаблонов) названия?

Question

Рассмотрим базу данных с таблицами «Продукты» и «Сотрудники».Появилось новое требование моделировать нынешних менеджеров по продуктам, поскольку они являются единственным сотрудником, ответственным за продукт, с учетом того, что некоторые продукты достаточно просты или достаточно зрелы, чтобы не требовать менеджера по продукту.То есть у каждого продукта может быть ноль или один менеджер по продукту.

Подход 1:изменить таблицу Product чтобы добавить новый NULLспособный столбец product_manager_employee_ID так что продукт без менеджера по продукту моделируется NULL ценить.

Подход 2:создать новую таблицу ProductManagers с не-NULLспособные столбцы product_ID и employee_ID, с уникальным ограничением на product_ID, так что продукт без менеджера по продукту моделируется отсутствием строки в этой таблице.

Есть и другие подходы, но с этими двумя я сталкиваюсь чаще всего.

Если предположить, что это оба законные дизайнерские решения (как я склонен верить) и просто представляют разные стили, есть ли у них названия?Я предпочитаю подход 2, и мне трудно объяснить разницу в стиле тому, кто предпочитает подход 1, не используя реальный пример (как я это сделал здесь!) Было бы хорошо, если бы я мог сказать: «Я предпочитаю подход 1». Склонность к 6NF (или как-то так) ставлю себе стиль».

Предположим, что один из этих подходов на самом деле является анти-шаблоном (что, как я только подозреваю, может быть в случае подхода 1 путем моделирования отношений между двумя объектами как атрибута одного из этих объектов), есть ли у этого анти-шаблона имя?

Answer 1

Ну, первый — это не что иное, как отношение «один ко многим» (один сотрудник ко многим продуктам).Иногда это называют отношением O:M (ноль ко многим), поскольку оно не является обязательным (не у каждого продукта есть менеджер по продукту).Кроме того, не каждый сотрудник является менеджером по продукту, поэтому с другой стороны это тоже необязательно.

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

Лично я предпочитаю первый вариант, но ни один из них не является неправильным (или плохим).

Второй вариант будет использоваться по двум причинам, которые приходят на ум.

1. Вы предполагаете, что у продукта будет более одного менеджера;или
2. Вы хотите отслеживать историю того, кто является менеджером по продукту.Вы делаете это, скажем, для столбца current_flag, установленного на «Y» (или аналогичного), где только один из них может быть текущим.На самом деле это довольно распространенный шаблон в приложениях, ориентированных на базы данных.

Answer 2

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

Answer 3

В первом подходе есть недостаток.Представьте на секунду, что бизнес-требования изменились и теперь вам нужно иметь возможность назначить к продукту двух менеджеров по продукту.Что вы будете делать?Добавить еще один столбец в таблицу Продукт?Фу.Тогда это явно нарушает 1NF.

Другой вариант, который дает второй подход, — это возможность хранить некоторые атрибуты для определенного отношения «Менеджер продукта <-> Продукт».Например, если у вас есть два менеджера по продукту, то вы можете назначить одного из них основным...Или, например, у сотрудника может быть номер телефона, но у него, как у менеджера по продукту, может быть другой номер телефона...Тогда это также попадает в специальную таблицу.

Answer 4

Подход 1)

1. Замедляет использование таблицы Product с дополнительным полем Product Manager (возможно, не для всех баз данных, но для некоторых).
2. Связать таблицу «Продукт» с таблицей «Сотрудники» очень просто.

Подход 2)

1. Существующие запросы, использующие таблицу Product, не затрагиваются.
2. Увеличивает размер вашей базы данных.Теперь вы продублировали столбец Product ID в другую таблицу, а также добавили в эту таблицу уникальные ограничения и индексы.
3. Связывание таблицы «Продукт» с таблицей «Сотрудники» более громоздкое и дорогостоящее, поскольку сначала необходимо выполнить рукописный ввод в промежуточную таблицу.

Как часто необходимо связывать две таблицы?

Сколько еще запросов используют таблицу Product?

Сколько записей в таблице Product?

Answer 5

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

есть обсуждение плюсов и минусов в Википедии.

Я почти уверен, что, учитывая нелюбовь c date к этому, он определяет реляционную теорию так, что только решение с несколькими таблицами является «действительным».например, вы можете назвать подход с одной таблицей «плохо типизированным» (поскольку тип null не понятно - см. цитату на стр. 4).