Каталог продукции Схема дизайна

Question

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

В нашем бизнесе мы продаем как физические материалы, так и услуги (одноразовые и повторяющиеся).заряды).

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

Идея, с которой я играю, заключалась в том, чтобы соответствовать базовому набору таблиц сущностей в 3-й нормальной форме,они будут содержать факты, которые являются общими для ВСЕХ продуктов.

Затем я хотел бы построить схему Entity-Attribute-Value, которая позволяет гибко расширять каждый тип сущности, используя только данные, а неизменения схемы.

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

У нас также есть много таблиц, которые содержат бизнес-правила и правила совместимости.Они будут объединяться с базовыми таблицами сущностей, а не с представлениями.

Мои большие опасения заключаются в следующем:

• Производительность - схемы Attribute-Entity-Value являются гибкими, но обычно работают плохо,я должен быть обеспокоен?
• Больше производительности - Денормализация с использованием материализованных представлений может иметь некоторые риски, я пока не уверен в этом.
• Сложность - Хотя эта схема является гибкой и поддерживаемой, используя только данныеЯ беспокоюсь, что сложность конструкции может затруднить будущие изменения схемы.

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

Answer 1

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

Я много раз говорил, что EAV похожи на наркотики: в небольших количествах и при правильном использовании они могут принести пользу; слишком много тебя убьет. Как правило, правило должно заключаться в том, что ни один запрос по строкам "Where Attribute = 'Foo'" или "Where AttributeValue = 'Bar'" не может быть разрешен для записи. Нет отчета, нет отображения; ничего такого. Любое использование EAV должно быть полностью динамическим и не зависеть от наличия определенного значения строки атрибута. В этом свете EAV действует как пакет данных. Его можно выложить в список в отчете. Вы можете разрешить пользователям выбирать атрибуты, которые они хотят видеть в отчете. Чего вы не можете сделать, так это фильтровать определенные значения EAV. Я слышал, что люди используют столбцы с данными XML для решения той же проблемы. В тот момент, когда кто-то хочет отфильтровать определенный атрибут, это является триггером, чтобы сделать этот атрибут атрибутом первого класса в виде столбца.

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

Answer 2

Хорошая идея - иметь одну общую таблицу PRODUCTS, но я не уверен, что вы выиграете от использования EAV для конкретных строк. В вашем решении нет дополнительной гибкости: если вы добавляете новый продукт, вам нужен новый материализованный вид; если вы добавляете новый атрибут к существующему продукту, вам нужно переопределить и перестроить материализованное представление, которое на самом деле ничем не отличается от обратных данных (за исключением того, что это, вероятно, займет больше времени).

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

Для меня кикер - это сложность: смешивание EAV и правильно определенных таблиц 3NF сбивает с толку. Кроме того, вы теряете возможность применять правила и ограничения реляционной целостности в базе данных для всех ваших конкретных продуктов.

Я думаю, что лучшим решением было бы сохранить предложенную таблицу ПРОДУКТОВ и использовать таблицы подтипов для отдельных строк. Когда вы приступите к моделированию, вы можете обнаружить, что вам нужен слой таблиц для различных типов продуктов - SERVICE_PRODUCTS и THING_PRODUCTS - и относительно немногие конкретные продукты нуждаются в собственной таблице. Вы можете использовать обычные представления для представления «денормализованных» проекций каждого продукта.