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