У этих стилей дизайна базы данных (или анти-паттерна) есть имена?

Question

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

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

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

Answer 3

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

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

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

Answer 4

Подход 1)

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

Подход 2)

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

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

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

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

Answer 5

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

Другой вариант, который дает второй подход, - это возможность сохранять некоторые атрибуты для определенного Product Manager <-> Product product. Например, если у вас есть два менеджера продукта для продукта, то вы можете установить один из них в качестве основного ... Или, например, у сотрудника может быть номер телефона, но в качестве менеджера по продукту у него / нее может быть другой номер телефона ... Это также относится к специальной таблице.