Стратегия проектирования базы данных: таблица продуктов в системе электронной торговли (EAV, наследование таблиц классов или наследование бетонных таблиц)

Question

Моя система электронной коммерции будет иметь 5 базовых типов продуктов:

1. Сотовые телефоны
2. Компьютеры
3. Обувь
4. Рубашки
5. По умолчанию (без определенного атрибута)

С каждым из них связаны определенные атрибуты ...

Что я сделал (наследование таблиц классов):

Product
   Id
   Name
   Sku
   Price
   ...   

Shoe
   ProductId 
   Size
   Color
   ...

Computer
   ProductId
   Memory
   Processor
   ...

Что вы думаете об этом дизайне?Я думаю, что это не очень хорошая идея, потому что это сделает код, который я немного усложнил, пример:

- Система показывает все товары на странице

- Теперь покупатель выбирает обувь

-Я получил ProductID и должен проверить, сотовый телефон или компьютер или обувь ...

Не знаю, может быть, я ошибаюсь ...

И я думаю, что EAV не очень хороший вариант ...

Что вы, ребята, думаете?

Спасибо

Answer 1

Существует как минимум три подхода к представлению наследования классов в базе данных

• Наследование одной таблицы : все атрибуты во всем дереве наследования хранятся в одной таблице и тамэто выделенный столбец, который описывает тип строки.Это означает, что будет много неиспользуемых столбцов, поэтому этот подход имеет смысл только тогда, когда подклассы совместно используют большинство атрибутов.
• Наследование таблицы классов : каждый класс в дереве сохраняется в отдельномтаблица базы данных, в которой хранятся только атрибуты, специфичные для данного класса.Это означает, что для извлечения объекта необходимо объединить таблицы, представляющие предков в дереве наследования.
• Наследование конкретной таблицы : для каждого конкретного класса существует отдельная таблица базы данных, новсе атрибуты, необходимые для данного класса, сохраняются, включая унаследованные.Это означает, что вам не нужно присоединяться, но, с другой стороны, вы не можете использовать upcast (например, когда вы запрашиваете продукты, вы не увидите обувь).

У каждого из этих подходов есть свои плюсы и минусы, вы должны сделать компромисс.

С другой стороны, использование наследования для представления типа продукта означает, что вы 'Вам придется изменять и код, и схему базы данных каждый раз, когда вы вводите новый тип продукта.Если типы будут сильно меняться, и с каждым типом будет мало логики, то может быть лучше использовать одну таблицу (productcId, key, value) свойств продукта.Это не красивый дизайн базы данных, но в таком случае он будет гораздо более практичным.

Answer 2

У вас хороший дизайн объекта.

Однако я предлагаю использовать наследование одной таблицы (как упоминалось Адамом) и держаться подальше от EAV. Если ваша СУБД поддерживает типы XML и вас беспокоит хранение всех полей NULLable, поместите все необязательные данные в один столбец XML. В этом случае проверка схемы гарантирует, что вы не будете пытаться сохранить тип процессора с помощью пары ботинок и т. Д.

Добавление дополнительных полей для каждого типа продукта так же просто, как обновить схему для этого конкретного продукта.

Answer 3

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