Лучший шаблон для хранения (продукта) приписывает в SQL Server

Это будет проблематично по нескольким причинам:

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

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

• Целостность данных ваших объектов находится под угрозой. Возникнет искушение поместить свойства, которые должны быть просто атрибутами ваших основных таблиц продуктов, в это "ведро с данными". Возможно, для начала дизайн будет полуразумным, но я гарантирую вам, что через некоторое время люди начнут просто бросать свойства в этот мешок. Тогда будет очень трудно поддерживать целостность объектов с такой слабо определенной структурой.

• Ваши индексы, скорее всего, будут неоптимальными. Снова подумайте о свойстве, которое должно быть в таблице продуктов. Вместо того, чтобы иметь возможность индексировать только один столбец, вы будете вынуждены создать потенциально очень большой составной индекс на таблице "тип".

• Поскольку вы, очевидно, планируете отказаться от правильных типов данных и использовать строки, производительность запросов диапазона для числовых данных, вероятно, будет низкой.

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

Лучше нормализовать таблицу более "традиционным" способом, используя отношения "IS-A". Например, у вас могут быть трубы, которые являются типом продукта, но имеют еще несколько атрибутов. У вас могут быть печи, которые являются типом продукта, но имеют еще несколько атрибутов.

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

IMO это антипаттерн проектирования. Песня сирены этой идеи заманила многих разработчиков на скалы необслуживаемого приложения.

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

Решение, IMO, является гибридом. Для общих атрибутов используйте столбцы / стандартную схему. Для дополнительных произвольных атрибутов используйте EAV. Однако правило с данными EAV заключается в том, что вы никогда, никогда и ни при каких обстоятельствах не можете написать запрос, который включает сортировку или фильтр по атрибуту. То есть вы никогда не сможете написать Где AttributeName = 'Foo' . Часть схемы EAV представляет собой пакет данных, который используется только для целей отслеживания. Фактически, я видел, как многие люди реализуют это решение, используя Xml для части EAV. В тот момент, когда кто-то действительно хочет найти, отфильтровать, отсортировать или поместить значение EAV в определенное место в отчете, этот атрибут должен быть повышен до столбца верхнего уровня в таблице продуктов.

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

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

Я использовал эту структуру раньше, и она работала достаточно хорошо.

Как отмечает @Dave Markle, именно-ценностный подход может привести к большому страданию.