Разработка схемы SQL Server

Question

У меня есть несколько отношений «Продукты - растения», которые мне нужны для создания таблиц в SQL SERVER.Продукт (около 8000) производится на всех 8 заводах, но редко (3-4 продукта из 8000). Продукт изготавливается на одном / двух заводах.

Я планирую внедрить отношения в одном издва пути.(Я знаю, что 1-й подход лучше, но 2-й подход проще для проектирования и разработки кода приложения).

1 - Отношение многие ко многим, в основном создайте третью таблицу ссылок ProductPlant.

2 - NullableСтолбец внешнего ключа PlantID в Таблице продуктов.Таблица продуктов будет иметь значение Null as PlantId (продукт, произведенный на ВСЕХ заводах) или PlantId, если он изготовлен на заводе.

Пожалуйста, предоставьте свое экспертное мнение.

Answer 1

Вы рисуете себя в углу с выбором № 2.

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

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

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

В-четвертых, вам нужно будет написать критерии выбора, такие как "где ProductID = CurrentProductID или ProductID равен нулю" повсеместно.Это может показаться простым для вас, но это точно не для меня.Я бы предпочел иметь дело с дополнительным объединением.

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

Если у вас есть много-много вариантов, воспользуйтесь распределительной таблицей.Вы пожалеете об этом, если не сделаете этого.

Answer 2

Создайте таблицу с именем ProductPlant или что-то в этом роде.Вот столбцы:

• ProductId
• PlantId

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

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

Answer 3

Я бы согласился с другими авторами о создании таблицы ProductPlant для идентификации продукта с конкретным заводом (или заводами, если требования меняются), но я бы пошел немного дальше и сказал, что вам нужно только заполнить эту таблицу для Исключения составляют не все 8000 товаров. Я бы добавил битовый флаг (или, может быть, вычисляемое поле?) В Product под названием IsAllPlants. Для тех, где этот флаг не установлен, таблица ProductPlant будет заполнена. Тогда запрос для поиска продуктов по PlantID будет таким простым: ВЫБЕРИТЕ * ИЗ ПРОДУКТА, ГДЕ IsAllPlants! = 0 ИЛИ ProductID IN (ВЫБЕРИТЕ ProductID ИЗ ПРОИЗВОДИТЕЛЯ ГДЕ PlantID = @PlantID)

Answer 4

IMO, гораздо лучше иметь третью таблицу, чтобы объединить их. Таким образом, не существует искусственного ограничения на количество заводов, на которых производится продукция. Если вы сделаете это иначе, вам понадобятся дубликаты записей о продуктах, если продукт производится на нескольких заводах. (Может быть, сегодня только один завод производит продукт, но как насчет завтра?)