Реализация гибких отношений в СУБД - Какие на самом деле компромиссы?

У меня есть набор продуктов с множеством различных возможных атрибутов для каждого продукта. Например. Товар А имеет название, размер, цвет, форму. У продукта B есть название, калории, сахар и т. Д. Один из способов решения этой проблемы:

1) Создание таблиц

Products (id, name)
Attributes (id, name)
Product_Attributes (product_id, attribute_id, value as string)

Это обеспечивает максимальную гибкость, но я слышал, что многие люди рекомендуют этого не делать, хотя я не знаю почему. Я имею в виду, если бы эти таблицы назывались «Команды, игроки», «Игроки команды», мы все согласились бы, что это правильный реляционный дизайн.

Каждый, кто объясняет мне, почему это плохо, делает это в контексте полностью гибкого реляционного дизайна, когда вы никогда не создаете настоящие таблицы после нескольких базовых базовых исходных таблиц (например, object, attribute, object_attribute), которые Я думаю, мы все можем согласиться, что это плохо. Но это гораздо более ограниченная и содержащаяся версия этого (только продукты, а не каждый объект в системе), поэтому я не думаю, что будет справедливо объединять эти две архитектуры вместе.

С какими проблемами вы столкнулись (опыт или теоретический), что делает этот дизайн настолько плохим?

2) Другой способ решить эту проблему - создать таблицу Product с кучей столбцов, таких как размер, цвет, форма, вес, сахар и т. д., а затем включить несколько дополнительных столбцов в конец, чтобы дать нам некоторую гибкость. Это приведет к созданию обычно разреженных строк, заполненных в основном значениями NULL. Людям, как правило, нравится этот подход, но мой вопрос в том, сколько столбцов вы можете иметь, прежде чем этот подход потеряет свои преимущества в производительности? Если у вас 200 столбцов, я думаю, это уже не разумный ход, но как насчет 100 столбцов? 50 столбцов? 25 столбцов?

3) Последний подход, о котором я знаю, - это хранить все атрибуты в виде большого двоичного объекта (возможно, JSON) в одном столбце таблицы Products. Мне нравится такой подход, но он кажется неправильным. Запросы сложные. И если вы хотите иметь возможность легко изменить имя атрибута позже, вам нужно либо проанализировать каждую запись отдельно, либо ввести их в свой BLOB-объект с помощью некоторого идентификатора. Если вы пойдете по пути id, вам понадобится еще одна таблица Attributes, и все начнет выглядеть как подход №1 сверху, за исключением того, что вы не сможете присоединиться к attribute_id со своим blob, поэтому я надеюсь, что вы не хотели ничего запрашивать по имени атрибута.

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

4) Я читал кое-что о возможности индексирования строго типизированных XML-форматов в некоторых СУБД, но, честно говоря, я мало что знаю об этом подходе.

Я застрял. Мне кажется, что подход №1 - лучший выбор, но все, что я читаю, говорит об этом, воняет. Как правильно думать об этой проблеме, чтобы решить, какой метод лучше всего подходит для данной ситуации? Разумеется, приветствуются больше идей, чем то, что я перечислил!