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

@StoneHeart

Я бы пошел сюда с EAV и MVC всю дорогу.

@Bill Karvin

вот некоторые из недостатков Подслушивание:

No way to make a column mandatory (equivalent of NOT NULL).
No way to use SQL data types to validate entries.
No way to ensure that attribute names are spelled consistently.
No way to put a foreign key on the values of any given attribute, e.g.

для таблицы подстановки.

все те вещи, которые вы упомянули здесь:

• проверка данных
• проверка орфографии имен атрибутов
• обязательные столбцы/поля
• обработка уничтожение зависимых атрибутов

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

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

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

эту проблему можно решить, сделав несколько запросов на частичные данные и обработав их в табличном макете с вашим приложением. Даже если у вас есть 600 ГБ данных продукта, вы можете обрабатывать их в пакетах, если вам нужны данные из каждой строки в этом стол.

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

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

Если вы все еще беспокоиться при выполнении операций, выполняемых приложением, вы всегда можете использовать Erlang, C++, Go Language для предварительной обработки данных, а затем просто обрабатывать оптимизированные данные дальше в своем основном приложении.

если я использую Class Table Inheritance значение:

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

что мне нравится больше всего из предложений Билла Карвина.. Я могу предвидеть один недостаток, который я попытаюсь объяснить, как не стать проблемой.

какой план действий я должен быть на месте когда атрибут, который является общим только для 1 типа, затем становится общим для 2, затем 3 и т. д.?

например: (это просто пример, а не моя реальная проблема)

если мы продаем мебель, мы продаем стулья, светильники, диваны, телевизоры и т. д. Тип телевизора может быть единственным типом, который мы носим, который имеет энергопотребление. Так что я бы поставил на tv_type_table. Но затем мы начинаем переносить системы домашнего кинотеатра, которые также имеют power_consumption собственность. Хорошо его только один другой продукт, поэтому я добавлю это поле в stereo_type_table а так как это, вероятно, проще всего на данный момент. Но со временем, когда мы начинаем носить все больше и больше электроники, мы понимаем, что power_consumption достаточно широк, что он должен быть в main_product_table. Что же мне теперь делать?

добавить поле main_product_table. Напишите скрипт, чтобы перебрать электронику и поставить правильное значение от каждого type_table до main_product_table. Затем отбросьте этот столбец от каждого type_table.

теперь, если бы я был всегда используя один и тот же GetProductData класс для взаимодействия с базой данных для извлечения информации о продукте; затем, если какие-либо изменения в коде теперь нуждаются в рефакторинге, они должны быть только для этого класса.

вы можете иметь таблицу Product и отдельную таблицу ProductAdditionInfo с 3 столбцами: идентификатор продукта, дополнительное имя информации, дополнительное значение информации. Если цвет используется многими, но не всеми видами продуктов, вы можете иметь столбец с нулевым значением в таблице Product или просто поместить его в ProductAdditionalInfo.

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

Стив Yegge называет это свойства pattern и написал длинный пост о ее использовании.