Суть проблемы такова:

В данный момент дописываю интернет магазин (компьютеры, комплектующие, портативные компы и тд).

К вопросу продумывания структуры базы подошел не совсем основательно, т.к. это первый более ни менее большой проект.
На начальном этапе, пока в базу добавлялись одни ноутбуки, нетбуки и тд, казалось бы, все нормально. Но вот дальшей встал вопрос о добавлении комплектухи и подобных товаров, т.к. у ноутбуков и им подобным кол-во аттрибутов (полей в таблице) ~24 + у каждого вида комплектующих еще по 5-6 уникальных для каждого вида аттрибутов, т.е. в процессе таблица должна расти в ширину, вроде и терпимо, но:

В поисках решения проблемы я отправился в интернеты. Ну и собственно для себя выделил два основных способа построения базы:



1) Single Table Inheritance (STI) - данная структура предполагает собой ОДНУ таблицу для всех товаров всех видов и, как я и предполагал, она будет рости в ширину и большинство полей в ней будет NULL-евыми. Вроде бы и кол-во товаров не должно превышать 5-6 тысяч ( по предварительным прогнозам ) т.е. таблица с примерно 40-50 полями и 5000-6000 строками без проблем будет возвращать нужные значения в считанные мгновения. И таки да, такая структура является реляционной БД, что для меня лично было откровением.

Тут в "админке" при добавлении товара в большую таблицу я просто указываю какие поля заполнять, остальные автоматом становятся NULL.



2)Entity-Attribute-Value (EAV) - предполагает собой разбиение товаров на три таблицы:

- Entity - Таблица, где хранится инфо о ВСЕХ товарах, но в виде 4-5 основных столбцов (одинаковых для всех). Таких как: id, навание, цена, производитель и тд.



-Attribute- хранит в себе весь список аттрибутов для каждого вида товара в виде (id_attribute, attr_value) т.е. получается довольно таки длинная таблица, как я понял. Если, допустим, будет 1000 ноутбуков по 15 уникальных параметров - это 15000 строк ( не так уж и много, но что есть то есть)



-Value- таблица, которая связывает Entity и Attribute внешними ключами, пары вида (id_product, id_attribute) т.е. размер ее будет чуть больше таблицы Attribute.



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



-Запросы будут ОЧЕНЬ(как по мне) большие. Чтобы вывести карточку товара нужно будет нехило натыкать INNER JOINов

-Сложность структуры, а в следствии и путаница возникает по части движка (оный пишу на PHP), опять все переделывать и тд.

-И вообще: стоит ли игра свеч ? При таком количестве товаров стоит ли извращаться таким образом ?


Лично я, больше склоняюсь к первому варианту, т.к. товаров, по сути, не очень много, как для интернет магазина. Ну и конечно число полей в таблице вряд ли превысит 50. А число записей 6000-7000.

Вот собственно что я хотел сказать и что спросить у умов программирования)

Спасибо за внимание!

Спасибо большое за ответы!

Да, действительно - не учел такой вариант!
Думал над чем-то подобным, когда есть главная таблица, goods(id,title,price,img) и есть таблица параметров, одна для всех товаров (id,id_good,par1,par2...), но это мне показалось теми же яйцами (STI) только в профиль).

Ваш вариант очень понравился )) Где-нибудь пробовали реализовать или видели реализации подобные ?
не будет проблем с фильтрацией и выборкой товаров ?