Неправильно ли использовать несколько внешних ключей, разделенных запятыми, и если да, то почему?

Есть две таблицы: Dealи DealCategories. Одна сделка может иметь много категорий сделок.

Таким образом, правильным способом должно быть создание таблицы DealCategoriesсо следующей структурой:

DealCategoryId (PK)
DealId (FK)
DealCategoryId (FK)

Тем не менее, наша аутсорсинговая команда сохранила несколько категорий в Dealтаблице следующим образом:

DealId (PK)
DealCategory -- In here they store multiple deal ids separated by commas like this: 18,25,32.

Я чувствую, что то, что они сделали, неправильно, но я не знаю, как четко объяснить, почему это неправильно.

Как мне объяснить им, что это неправильно? Или может я тот, кто не прав и это приемлемо?

Да, это ужасная идея.

Вместо того, чтобы идти:

SELECT Deal.Name, DealCategory.Name
FROM Deal
  INNER JOIN
     DealCategories ON Deal.DealID = DealCategories.DealID
  INNER JOIN
     DealCategory ON DealCategories.DealCategoryID = DealCategory.DealCategoryID
WHERE Deal.DealID = 1234

Теперь вам нужно идти:

SELECT Deal.ID, Deal.Name, DealCategories
FROM Deal
WHERE Deal.DealID = 1234

Затем вам нужно сделать что-то в коде приложения, чтобы разбить этот список запятых на отдельные числа, а затем запросить базу данных отдельно:

SELECT DealCategory.Name
FROM DealCategory
WHERE DealCategory.DealCategoryID IN (<<that list from before>>)

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

Антипаттерны SQL (Karwin, 2010) посвящают этому антипаттерну целую главу (которую он называет «Jaywalking»), страницы 15-23. Кроме того, автор разместил на аналогичный вопрос в SO . Ключевые моменты, которые он отмечает (применительно к этому примеру):

• Запрашивать все сделки в определенной категории довольно сложно (самый простой способ решить эту проблему - это регулярное выражение, но регулярное выражение само по себе является проблемой).
• Вы не можете навязать ссылочную целостность без отношений внешнего ключа. Если вы удалите DealCategory Nr. # 26, вы затем, в своем коде приложения, должны пройти каждую сделку в поисках ссылок на категорию # 26 и удалить их. Это то, что должно быть обработано на уровне данных, и необходимость обрабатывать это в вашем приложении - очень плохая вещь .
• Совокупные запросы ( COUNTи SUMт. Д.), Опять же, варьируются от «сложных» до «почти невозможных». Спросите ваших разработчиков, как они могут получить список всех категорий с подсчетом количества сделок в этой категории. При правильном дизайне это четыре строки SQL.
• Обновления становятся намного сложнее (т.е. у вас есть сделка в пяти категориях, но вы хотите удалить две и добавить еще три). Это три строки SQL с правильным дизайном.
• В конце концов вы столкнетесь с VARCHARограничениями длины списка. Хотя если у вас есть разделенный запятыми список длиной более 4000 символов, есть вероятность, что в любом случае монстр будет работать очень медленно.
• Вытащить список из базы данных, разделить его, а затем вернуться к базе данных для другого запроса, по сути, медленнее, чем один запрос.

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

Однако наша аутсорсинговая команда сохранила несколько категорий в таблице сделок следующим образом:

DealId (PK) DealCategory - здесь они хранят несколько идентификаторов сделок, разделенных запятыми, например: 18,25,32.

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

Но это ужасно, если вы хотите знать все предложения в данной категории.

И это также делает действительно трудным и подверженным ошибкам делать что-либо еще - например, обновления, подсчеты, объединения и т. Д.

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

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

Несколько значений в столбце соответствуют первой нормальной форме.

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

Правильная реализация будет соединительной таблицей, такой как «DealDealCategories», с DealId и DealCategoryId.

Плохая реализация иерархии?

Кроме того, FK в DealCategories другой DealCategory выглядит как плохая реализация иерархии / дерева DealCategories. Работать с деревьями через отношение Parent ID (так называемый список смежности) очень сложно!

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