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




Спустя 12 минут, 43 секунды (12.07.2012 - 14:03) kamanch написал(а):
Если с PrestaShop имел дело, то можешь туда глянуть. Там как раз реализовано то, что ты хочешь. И, на мой взгляд, так оно и должно быть.

Таблица products // Товары
p_id;
и т.д.

Таблица features // Название свойств товаров
f_id;
f_name;

Таблица features_values // Значения свойств товаров
fv_id;
f_value;

Таблица features_names_values // Название свойства-Значение свойства (для админки)
f_id;
fv_id;


Таблица products_features // Товар-Название свойства-Значение свойства
p_id;
f_id;
fv_id;

Спустя 41 минута, 46 секунд (12.07.2012 - 14:44) battrack написал(а):
Жесть! Неужели так геморно придется делать!

Спустя 20 минут, 20 секунд (12.07.2012 - 15:05) T1grOK написал(а):
Может и геморно зато правильно. И когда нужно будет как то модифицировать БД не нужно будет лезть через ОПУ.

Спустя 14 минут, 38 секунд (12.07.2012 - 15:19) kamanch написал(а):
Цитата
Давно занимаюсь разработкой сайтов и интернет-магазинов.

Видимо, не так уж и давно, либо давно, но не так уж и много.
Иначе гемор бы уже давно начался, если реализация другая.
А при приведенной мной архитектуре БД все лежит на своих местах и не мешает соседям.

Дополню, чтобы было понимание, для чего такой "гемор"

Таблица products // Товары - тут все ясно.

У каждого товара может быть множество свойств (цвет, размер, год выпуска и т.д.), следовательно, нам необходима
Таблица features // Название свойств товаров

У каждого свойства может быть несколько значений (цвет: красный, синий, зеленый...), следовательно, нам необходима
Таблица features_values // Значения свойств товаров

В админке мы добавляем к товару свойство, а потом должны из списка значений свойств выбрать значения, присущие только для этого свойства (размер не может быть зеленым). В тоже время, у некоторых разных свойст могут быть общие значения (например для фильма: год выпуска и дата выхода в прокат в России), следовательно, нам необходима
Таблица features_names_values // Название свойства-Значение свойства (для админки)

Ну, и для вывода свойств товара на сайте
Таблица products_features // Товар-Название свойства-Значение свойства

Спустя 1 час, 22 минуты, 15 секунд (12.07.2012 - 16:41) vagrand написал(а):
Очень хорошо такую задачу реализовать на MongoDB, что бы ничего не переделывать можно MongoDB использовать только для свойст товара.

Спустя 4 дня, 20 часов, 34 минуты, 14 секунд (17.07.2012 - 13:16) battrack написал(а):
Получается что если товару свойственно какое-то "свойство" (простите за тофтологию), то в таблице products_features и происходит связь товара и свойства? Т.е. там связывается id товара с id свойства и вписывается значение свойства?

Соответственно при заполнении этого свойства у товара происходит добавление записи в таблицу products_features, а если это свойство у этого товара не заполнено, то запись не создается (или удаляется если уже была создана). Так?

Спустя 12 минут, 58 секунд (17.07.2012 - 13:29) battrack написал(а):
Таблица features_names_values // Название свойства-Значение свойства (для админки)
f_id;
fv_id;

В этой таблице мы связываем свойства с возможными их значениями, если я правильно понял.
А как же тогда быть со свойствами, которые должны иметь ОДНО значение? Т.е. не должно выбираться из выпадающего списка в админке, а вписываться вручную. Как вы говорили, например "год выпуска фильма". Получается что такое свойство не будет отображено в таблице features_names_values, т.к. для него не существует подборки значений?
И получается что значение этого свойства сразу должно быть вписано в таблицу products_features в поле features_value? Хотя в вашей версии такого поля нет, а есть поле fv_id куда вписывается id значения свойства...

Спустя 6 минут, 32 секунды (17.07.2012 - 13:35) DarkLynx написал(а):
Цитата (battrack @ 17.07.2012 - 10:16)
Получается что если товару свойственно какое-то "свойство" (простите за тофтологию), то в таблице products_features и происходит связь товара и свойства? Т.е. там связывается id товара с id свойства и вписывается значение свойства?

Соответственно при заполнении этого свойства у товара происходит добавление записи в таблицу products_features, а если это свойство у этого товара не заполнено, то запись не создается (или удаляется если уже была создана). Так?

Да.

Спустя 4 минуты, 17 секунд (17.07.2012 - 13:40) DarkLynx написал(а):
Цитата (battrack @ 17.07.2012 - 10:29)
Таблица features_names_values // Название свойства-Значение свойства (для админки)
f_id;
fv_id;

В этой таблице мы связываем свойства с возможными их значениями, если я правильно понял.
А как же тогда быть со свойствами, которые должны иметь ОДНО значение? Т.е. не должно выбираться из выпадающего списка в админке, а вписываться вручную. Как вы говорили, например "год выпуска фильма". Получается что такое свойство не будет отображено в таблице features_names_values, т.к. для него не существует подборки значений?
И получается что значение этого свойства сразу должно быть вписано в таблицу products_features в поле features_value? Хотя в вашей версии такого поля нет, а есть поле fv_id куда вписывается id значения свойства...

Каким образом получены значения свойств роли не играет никакой..
Хоть через список, хоть вручную, хоть через чекбоксы.
Вам показали основную идею структурирования данных. А именно, хранить названия свойство отдельно, значения отдельно и как следствие появляется таблица связи. Вы спрашиваете именно про таблицу связей, которой вообще до фонаря что там за свойства и тем более как они были получены.

Спустя 2 часа, 50 минут, 27 секунд (17.07.2012 - 16:30) battrack написал(а):
Подход, который вы мне разжевали, мне очень нравится. Спасибо большое!

Спустя 3 часа, 50 минут, 22 секунды (17.07.2012 - 20:20) kamanch написал(а):
Цитата
В этой таблице мы связываем свойства с возможными их значениями, если я правильно понял.
А как же тогда быть со свойствами, которые должны иметь ОДНО значение? Т.е. не должно выбираться из выпадающего списка в админке, а вписываться вручную. Как вы говорили, например "год выпуска фильма". Получается что такое свойство не будет отображено в таблице features_names_values, т.к. для него не существует подборки значений?
И получается что значение этого свойства сразу должно быть вписано в таблицу products_features в поле features_value? Хотя в вашей версии такого поля нет, а есть поле fv_id куда вписывается id значения свойства...


Не поленись, скачай PrestaShop - он ставится 10 минут и заведи там пару товаров с различными свойствами, паралельно заглядывая в базу. Увидишь там все движения и поймешь сразу.

Тебе там нужны будут таблицы:
ps_product
ps_feature
ps_feature_lang
ps_feature_product
ps_feature_value
ps_feature_value_lang

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

и

ps_feature_value
ps_feature_value_lang

В твоем случае, для каждой пары будет по одной таблице

Спустя 1 месяц, 4 часа, 58 минут, 44 секунды (18.08.2012 - 01:19) moricone2 написал(а):
Тоже возник у меня вопрос по этой теме.Спланировал таблицы, как было рекомендовано выше(5 таблиц) и создаю запросы для поиска.Например, поиск товаров, если features.f_name='color' and features_values.f_value='black'. Товары выводяться нормально;ниже -запрос. А как сделать, если несколько выбрано свойств для поиска? Например, f_name ='color' and f_value='black' , а также f_name ='firm' and f_value='Samsung' (должно вывести товыры фирмы Samsung черного цвета; если с помощью OR обьединять условия-выводит не то, что надо)


SELECT p_name, f_name, f_value
FROM products, features, features_values, features_names_values, products_features
WHERE products.p_id = products_features.p_id
AND products_features.f_id = features_names_values.f_id
AND products_features.f_id = features.f_id
AND products_features.fv_id =features_names_values.fv_id
AND products_features.fv_id =features_values.fv_id
AND features.f_name='color'
AND features_values.f_value='black'

Спустя 2 дня, 16 часов, 30 минут, 52 секунды (20.08.2012 - 17:50) moricone2 написал(а):
Скажите пожалуйста, кто, что думает по предыдущему сообщению; может, надо таблицы как-то по другому спланировать?


_____________
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.