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

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

Table Product ( id PK, name, price, units_per_package)
Table Product_Attribs (id FK ref Product, AttribName, AttribValue)

Который позволил бы Вам присоединять список атрибутов к продуктам. - Это - по существу Ваша опция 3

Если Вы знаете макс. количество атрибутов, Вы могли бы пойти

Table Product (id PK, name, price, units_per_package, attrName_1, attrValue_1 ...)

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

Я предпочитаю первую опцию потому что

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

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

Второе решение, которое Вы описываете, называют "Полиморфными Ассоциациями", и это бесполезно. Ваш "внешний ключ" не является реальным внешним ключом, таким образом, Вы не можете использовать ограничение DRI для обеспечения целостности данных. Полиморфизм OO не имеет аналога в реляционной модели.

Третьим решением, которое Вы описываете, включая хранение названия атрибута как строка, является дизайн под названием "Значение атрибута объекта", и можно сказать, что это - болезненное и дорогое решение. Нет никакого способа гарантировать целостность данных, никакой способ сделать один атрибут NOT NULL, никакой способ удостовериться, что данный продукт имеет определенный набор атрибутов. Никакой способ ограничить один атрибут против справочной таблицы. Много типов агрегатных запросов становятся невозможными сделать в SQL, таким образом, необходимо записать много кода приложения, чтобы сделать отчеты. Используйте дизайн EAV, только если Вы должны, например, если у Вас есть неограниченное количество типов продукта, список атрибутов может отличаться на каждой строке, и Ваша схема должна часто размещать новые типы продукта без изменений кода или схемы.

Другим решением является "Наследование Единственной Таблицы". Это использует чрезвычайно широкую таблицу со столбцом для каждого атрибута каждого продукта. Отпуск АННУЛИРУЕТ в столбцах, которые не важны продукту на данной строке. Это эффективно означает, что Вы не можете объявить атрибут как NOT NULL (если это не находится в группе, характерной для всех продуктов). Кроме того, большинство продуктов RDBMS имеет предел на число столбцов в единственной таблице или общей ширины в байтах строки. Таким образом, Вы ограничены в количестве типов продукта, можно представить этот путь.

Гибридные решения существуют, например, можно обычно хранить общие атрибуты, в столбцах, но определенных для продукта атрибутах в таблице Entity-Attribute-Value. Или Вы могли сохранить определенные для продукта атрибуты некоторым другим структурированным способом, как XML или YAML, в столбце BLOB таблицы продуктов. Но эти гибридные решения страдают, потому что теперь некоторые атрибуты должны быть выбраны по-другому

Окончательное решение для таких ситуаций состоит в том, чтобы использовать семантическую модель данных, с помощью RDF вместо реляционной базы данных. Это совместно использует некоторые характеристики с EAV, но это намного более амбициозно. Все метаданные хранятся таким же образом как данные, таким образом, каждый объект самоописывает, и можно запросить список атрибутов для данного продукта, как Вы запросили бы данные. Специальные продукты существуют, такие как Йена или Сезам, реализовывая эту модель данных и специальный язык запросов, который отличается, чем SQL.

Нет никакого чудодейственного средства, которое Вы пропустили.

Вы имеете то, что иногда называют "непересекающимися подклассами". Существует суперкласс (продукт) с двумя подклассами (ProductX) и (ProductY). Это - проблема, которая - для реляционных баз данных - Действительно Трудна. [Другой тяжелой проблемой является Перечень материалов. Другой тяжелой проблемой являются Графики Узлов и Дуг.]

Вы действительно хотите полиморфизм, где OrderLine связан с подклассом продукта, но не знает (или уход) который определенный подкласс.

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

1. Продвиньте все до суперкласса. Это - подход uni-таблицы, где у Вас есть продукт с различителем (тип = "X" и тип = "Y") и миллион столбцов. Столбцы продукта являются объединением столбцов в ProductX и ProductY. Будут пустые указатели повсеместно из-за неиспользованных столбцов.

2. Снизьте все в подклассы. В этом случае Вам будет нужно представление, которое является объединением ProductX и ProductY. То представление - то, к чему присоединяются для создания полного порядка. Это похоже на первое решение, кроме оно создается динамично и не оптимизирует хорошо.

3. Соедините Суперэкземпляр класса для разделения на подклассы экземпляра. В этом случае Таблица product является пересечением столбцов ProductX и ProductY. Каждый продукт имеет ссылку на ключ или в ProductX или в ProductY.

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

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

Преимущество состоит в том, что можно описать обработку кратко и правильно. Как объекты, с отношениями подкласса.

Недостаток - то, что Ваш SQL передает к упрощенным объемным выборкам, обновляет и вставляет.

Это становится преимуществом, когда SQL изолируется на уровень ORM и управляется как своего рода тривиальная деталь реализации. Программисты Java используют iBatis (или В спящем режиме или TopLink или Кокон), Python программисты используют SQLAlchemy или SQLObject. ORM делает выборки базы данных и сохраняет; Ваше приложение непосредственно управляет Заказами, Строками и продуктами.

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

Я составил бы таблицы как это:

Attribute(attribute_id, description, is_listed)    
-- contains values like "colour", "width", "power source", etc. 
-- "is_listed" tells us if we can get a list of valid values: 

AttributeValue(attribute_id, value)
-- lists of valid values for different attributes.  

Product (product_id, description)

ProductAttribute (product_id, attribute_id)  
-- tells us which attributes apply to which products

Order (order_id, etc)

OrderLine (order_id, order_line_id, product_id)

OrderLineProductAttributeValue (order_line_id, attribute_id, value)
-- tells us things like: order line 999 has "colour" of "blue"

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

Мы делаем подобные вещи со многими типами объекта.

Chris и AJ: Спасибо за Ваши ответы. Линейка продуктов может измениться, но я не назвал бы ее "энергозависимой".

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

Я был на самом деле вовлечен в прошлый проект, где определение продукта было сделано таким образом. Мы по существу создали полную систему определения атрибута продукта/продукта (типы данных, минимальные случаи / макс. случаи, значения по умолчанию, 'потребовали' флагов, сценарии использования и т.д.), система работала, в конечном счете, но шла со значительной стоимостью в издержках и производительности (например, осуществил представления для визуализации продуктов, пользовательские "умные" компоненты, чтобы представить и проверить ввод данных UI для определения продукта, другой "умный" компонент для представления настраиваемых атрибутов экземпляра продукта на строке порядка, и тому подобное).

Еще раз спасибо за Ваши ответы!