Каков общий способ создания отношений «многие ко многим»?

Question

У меня есть 2 таблицы Product, которые содержат товары магазина, и ProductStatus, которые указывают, является ли продукт новым, проданным и т. Д. Один продукт может иметь много статусов.

Мне нужно связать продукт и статус.Я подумал о двух способах:

1. добавить 3-ю таблицу ProductToStatus, которая будет соответствовать ProductId с ProductStatusId
2. добавить Status столбецна Product таблицу, которая будет содержать идентификаторы статусов, разделенных запятыми («4,12,34,»);

Какие плюсы и минусы каждого решения выше или, возможно, есть другоеобщий способ сделать это?

Answer 1

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

Ее основные преимущества перед предлагаемым вами вторым способом:

• проверка ограничений - вы можете объявить столбцы ProductId и ProductStatusId как внешние ключи, и база данных не позволит вам присвоить несуществующий статус для продукта.

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

Answer 2

Вариант 1, безусловно, лучше и наиболее часто используется, поскольку вы можете настроить таблицу ссылок (ProductToStatus) с внешними ключами для обеих таблиц, которые будут поддерживать целостность данных.

Answer 3

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

Answer 4

Для модели следует использовать альтернативу 1.Альтернатива 2 - уродливый обходной путь.

Вы даже не сможете создать ФК, если используете альтернативу 2.

Answer 5

Проблема с вариантом 2 заключается в том, что ваша новая структура данных несовместима с операторами SQL. Например, значение "4,12,34," должно рассматриваться как то же самое, что и "4,34,12,": в отсутствие возможности перегрузки операторов SQL вам необходимо: а) писать пользовательские функции и б) обучать пользователей использовать UDF, а не Операторы SQL. Повторите для каждого оператора.

То же самое относится и к ограничениям. Например, вам нужно запретить значение "4,12,4,", поскольку оно содержит повторяющиеся элементы. Опять же, вам нужно свернуть свои собственные ограничения, предположительно с использованием ограничений SQL CHECK.

В процессе написания этих операторов и ограничений вам всегда нужно будет разделять элементы, оператор над ними, а затем объединять их снова. Кто бы задал вопрос: почему бы просто не разлучить их? Тогда мы вернемся к варианту 1!