Sql Table динамический тип ячейки

Question

Допустим, у меня есть таблица Product и ProductType.Я хочу таблицу, где я могу хранить специальные столбцы для каждого типа продукта.Специальные столбцы (атрибуты) могут быть любого типа.

Прямо сейчас у нас есть таблица на ProductType с именем Product_%ProductTypeId%, которая мне действительно не нравится - какие-либо предложения?

Моя идея состояла в том, чтобы иметь таблицу ProductTypeColumns с столбцами:

Id | ProductTypeId | ColumnName | Value  | ColumnType

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

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

Answer 1

Это называется EAV .
Вы можете найти некоторые вопросы о EAV и SQL Server здесь на SO:

• EAV через SQL Server
• Производительность больших систем EAV / открытых схем на SQL Server

Это тема, в которой у многих людей разные мнения.
Некоторые скажут, что вам следует придерживаться Product_%ProductTypeId% таблиц, а некоторые скажут, что ваш ProductTypeColumns стол - лучший способ.

По сути, я нахожусь в ProductTypeColumns лагере.
Мы используем нечто подобное и на работе:
Наша таблица содержит атрибуты для элементов заказа (более миллиона элементов заказа и более 250 миллионов атрибутов), и мы используем их уже почти десять лет.
Недостатки: отсутствие безопасности типов (как вы уже упоминали) и запрос может быть немного сложнее .

Но для нас это единственный возможный способ, потому что у нас более 1000 атрибутов, более 100 продуктов, и каждый продукт может иметь от 100 до 300 атрибутов. С такими размерами таблица атрибутов является единственным возможным способом.
Но, вероятно, это не лучшее решение для всех, и я не знаю, будет ли это лучшим решением для вас.

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

Как часто, это зависит.

Answer 2

Как насчет иерархии категорий (иначе говоря, "наследование", "подтип", "подкласс")?

Я бы лично выбрал решение для пары имя / значение (описано в вашем вопросе), только если столбцы не предопределены.

Если вы знаете все столбцы заранее, и они вряд ли изменятся, то реализация иерархии категорий , хотя и не без осложнений , сохранит безопасность типов и обеспечит более эффективную реализацию декларативной целостности СУБД ( например, для конкретного продукта может быть установлено ограничение UNIQUE, FOREIGN KEY или CHECK).