[battrack]

Давно занимаюсь разработкой сайтов и интернет-магазинов. Наработал уже довольно своих кодов и библиотек. Сайты делаю на основе своей рукописной CMS (прошу сразу не забрасывать помидорами, вопрос не о том).
Не смотря на то, что занимаюсь интернет-магазинами давно, как-то так получилось , что всегда у товаров в каталоге НЕ ФИКСИРОВАННЫЙ НАБОР характеристик. Т.е. всегда получалось так, что магазин был довольно узконаправленный и в администрировании каталога при добавлении/редактировании товаров приходилось заполнять определенный набор полей (ну, скажем, для товара «сумка» характеристики: цвет, материал, бренд и т.д.). Т.е. набор характеристик был фиксирован для всех товаров и какие-то из характеристик можно было заполнять, какие-то нет.
Сейчас встала другая задача. Теперь делаю магазин в котором огромное разнообразие товаров: начинаю от чехлов для телефонов и заканчивая холодильниками. Сами понимаете, набор характеристик для всех товаров (или групп товаров) будет свой. Если у телевизора есть «диагональ экрана», то у джойстика для приставки такой характеристики нет. У принтера есть характеристика «цветной/не цветной» а у чехла для телефона такой характеристики нет. Ну.. короче вы поняли о чем речь…
Собственно и встала задача разработать в движке функционал по добавлению/редактированию характеристик товаров в виде отдельного списка. А уже в самих товарах активировать и заполнять те или иные характеристики из созданного списка характеристик.
С точки зрения администратора (т.е. пользователя кто будет админить каталог) все более менее понятно. Ковырял другие cms-ки (как платные и бесплатные) и видел как у них в интерфейсе все это реализуется. Не до конца мне понятно другое – как это делать на программном уровне, а точнее даже на уровне проектирования базы данных.
С давних пор у меня в базе всегда была таблица «products» в которой собственно и хранились все товары. У таблицы были поля: id, parent_id, name, code, price и т.д. – короче все как обычно. И соответственно кроме этих полей были еще поля характеристик: color, size, descriprion_big, description_small и т.д. Набор этих полей, как я писал выше, у меня всегда был фиксированным.
Так вот вопрос в том – как правильно спроектировать базу данных при наличии в админке таблицы характеристик товара? Ведь не правильно же делать набор полей таблицы products динамическим? Т.е. при добавлении новой характеристики товара в админке, в базе данных в таблице products появится новое поле? Правильно ли я понимаю, что это не совсем верно и корректно?
Может быть должна иметься отдельная таблица для характеристик товаров и каждая запись в ней – это характеристика. А потом эту таблицу как-то привязывать к своей таблице товаров?
Короче говоря в этом вопросе я встал в ступор и пока не нахожу решения. Сейчас думаю поставить какой-нибудь известный движок, поэкспериментировать с ним и посмотреть что будет происходить в базе данных.
Ведь задача то тривиальная и подозреваю, что уже существует какое-то отработанное стандартное грамотное решение.
Может кто подскажет?

[JohnJ]

Ну вы правы в последнем предположении. Создаёте таблицу products, в которой хранятся общие для всех видов товаров параметры, например:
id, category_id, name, price, creator
И вторую таблицу products_parameters вида:
id, product_id, parameter_id, value
где product_id указывает на товар из таблицы products с id = product_id. Таким образом у каждого товара может быть до нескольких параметров, хранящихся в другой таблице. И каждый будет в своей строке записан.
Так же рекомендую сделать таблицу для категорий товаров: category_parameters
id, category_id, parameter_name
В ней будет храниться список параметров для каждой категории товаров. Тоже по одному в строке.
В админке в свойствах категории должен быть список (проще всего текстовое поле), в котором можно будет редактировать эти значения. А при редактировании товара скрипт будет считывать эту таблицу по category_id товара, и выдавать поля, которые нужно заполнить. А так же скрипт будет считывать таблицу products_parameters для данного товара и вставлять уже заполненные данные. При этом нужно учесть, что список полей для товара мог поменяться и в результате в товаре могли оказаться поля, которые уже не существуют в категории. Такие нужно либо удалять, либо при редактировании категории проверять и сообщать администратору, что есть товары, которые используют данный параметр. И выводить вопрос на подтверждение - удалить параметр или нет. Кстати, лучше предупредить об осторожном редактировании таких параметров. Иначе, если параметр "цвет" переименуют в "размер", то могут появиться товары с размером "синий, красный, зелёный"...

[JohnJ]

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

[maxefect]

JohnJ, а в какой программке делаешь блоки? А то я пользуюсь Mind Manager, просто интересно еще увидеть аналоги

[JohnJ]

я не делаю блоки обычно
А тут сделал с помощью онлайн-сервиса:
http://ondras.zarovi.cz/sql/demo/
Правда в Опере он у меня не функционирует (меню не появляется), зато в ff работает.
А mind manager - это что-то типа "карты памяти"? Как на нём БД можно проектировать? В качестве карты памяти я использую XMind...

[battrack]

JohnJ, спасибо за развернутый ответ! Все понятно!
Только вот вопрос в том: как быть с параметрами, которые имеют опционное значение?
Ну, например, параметр "цвет". У него может быть несколько значений: синий, зеленый и т.д.

Т.е. в админке должно быть два вида параметров:
1. Поле ввода, в которое просто вписывается значение параметра. Например "частота процессора" - вписываем в поле значение частоты (1Гц).
2. Выпадающий список, в котором выбираем одно из доступных значений параметра. Например "цвет" и в списке выбираем "синий", "зеленый" и т.д.

Добавлено через 50 секунд

Наверное тогда нужна еще одна таблица для связи id параметра и подбора значений для него.

[JohnJ]

Наверное тогда нужна еще одна таблица для связи id параметра и подбора значений для него.

Можно и так, но можно проще: в таблице свойств категории добавить поле "parameter_values", где будут, если это необходимо, указываться различные параметры. Их можно задавать через разделитель (запятая , двоеточие : или двойное двоеточие ::, или вовсе что-то ещё), а можно записывать сериализованный массив. В вашем случае, смею предположить, проще всего использовать именно запятую. В админке создаётся поле для товаров категории (в свойствах категории) и указывается, если нужно, набор возможных величин. Например, параметр цвет для определённой категории будет содержать всего несколько цветов, тогда в БД запишется так:
parameter_name: "цвета"
parameter_values "красный, зелёный, жёлтый, синий"
Для текстовых полей в форме заполнения данных о товаре parameter_values будет пустым. А если он не пуст - формируем массив с помощью функции explode, и из массива составляем опции html-элемента select
Главное, не ошибиться с типом поля parameter_values в БД: чтобы длинные списки не обрезались, лучше поставить тип TEXT

А в таблице products_parameters хранить значение полностью, не индексом, так как в подобных полях список возможных значений может часто изменяться.