Лучшие практики и / или советы для таблиц алмазных отношений (Linq to SQL)

Question

Мне нужно импортировать содержимое 4 таблиц из старой базы данных в SQL 2005 для упрощения отчетов.

Продукты содержит идентификатор и название продукта, ProductProperties содержит переменное количество свойств для каждого продукта, Ингредиенты содержит переменное количество ингредиентов для каждого продукта и IngredientProperties содержит те же свойства, что и продукт, указанный для каждого ингредиента.

альтернативный текст http://www.freeimagehosting.net/uploads/15068ece48.png

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

В настоящее время я извлекаю все строки из IngredientProperties для данного IdProduct и создаю из этого отчет, но я хотел бы использовать внешние ключи для разрешения будущих обновлений данные.

Каков рекомендуемый дизайн взаимосвязей таблицы IngredientProperties для лучшего использования с Linq?

Два образца отчетов:

// IdProduct = 1

        Price  Density
A1   25       10
A2   56       14

// IdProduct = 2

        Price  Density  Opacity
B1   87       21          60
B2   50       31          70
B3   12       10          90

Answer 1

Похоже, у вас есть дизайн Entity-Attribute-Value в вашей таблице IngredientProperties. Эти типы дизайнов могут быть совершенно опасными, если вы не до смешного дотошны при создании своих ограничений. Исходя из того, что вы уже рассказали о рассматриваемой проблеме, вы можете изменить схему и не указали необходимость поддержки произвольных свойств.

Если список свойств действительно предопределен и будет редко меняться, я бы превратил их в столбцы для схемы, которая выглядела бы примерно так, с некоторыми ограничениями стиля:

CREATE TABLE Ingredients(
    ProductID int IDENTITY NOT NULL PRIMARY KEY,
    SerialNum varchar(15) NOT NULL UNIQUE,
    Opacity int,
    Density int
);

CREATE TABLE Ingredients(
    IngredientID int IDENTITY NOT NULL PRIMARY KEY,
    ProductID int NOT NULL FOREIGN KEY REFERENCES Products (ProductID),
    SerialNum varchar(15) NOT NULL UNIQUE,
    Price money NOT NULL,
    Opacity int,
    Density int
);

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

Answer 2

Ваши красные стрелки означают, что у продукта не может быть строк в IngredientProperties , если у продукта не было хотя бы одной подходящей строки в ProductProperties . Имеет ли смысл, что ингредиенты продукта не могут иметь плотность, пока продукт не имеет плотности? Это ограничение не существует только с ФК «черная стрелка».

(Имеет ли смысл повторять свойства для каждого продукта? Различаются ли плотность, непрозрачность или цена ингредиента А1 в зависимости от того, в какой продукт он включен?)

FK от IngredientProperties до Ingredients имеет смысл, но это должен быть один агрегированный ключ, а не два отдельных FK, что означает, что PK на Ingredients также должен быть агрегированным ключом, то же самое относится и к ProductProperties .

Edit:

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

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

Я подозреваю, что красная стрелка сверху неверна. Есть две строки PropertyKey , но я не думаю, что они представляют одну и ту же вещь, поскольку в каждой таблице есть отдельная PropertyValue . Одна пара представляет свойства продуктов, а другие - ингредиенты, поэтому связывание их вместе вызовет путаницу.

Я все еще не уверен на 100%, что вы ищете, но вот мои рекомендации:

1. Настройка (или сохранение) PK / индексов для каждой таблицы, как представлено пунктами в заголовках, обведенными кружком.
2. Установите FK для соответствия черным стрелкам из Ingredients и PropductProperties .
3. Настройте FK в соответствии с зелеными стрелками.

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

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