Вариант структуры БД: Товары, Категории, Производители, Характеристики товаров. Есть?

Гриша К.

Новичок
Вариант структуры БД: Товары, Категории, Производители, Характеристики товаров. Есть?

Здравствуйте.

Сейчас структура таблицы товаров в БД такая (в кратце):
PRODUCTS (product_id, cat_id, firm_id, product_name, product_description)


При просмотре товаров определнного раздела, я хотелбы:
1) Ввыводить список всех производителей данного раздела, чтобы в дальнейшем пользователь мог выбирать производителя из списка и просматривать только его товары.
2) Задовать для товаров различные характеристики (например: размер, цвет), выводить список характеристик для категории, чтобы в последующем пользователь мог выбрать характеристики и товары выводились только с выбранными характеристиками.

Таблицы решил составить следующим образом:
# Товары # PRODUCTS (product_id, product_name, product_description)
# Товары по категориям # PRODUCT_CATEGORY (product_id, cat_id)
# Товары по производителям # PRODUCT_FIRM (product_id, firm_id)
# Названия характеристи # CHARACTERISTICS (char_id, char_name)
# Значение характеристики для товара # PRODUCT_CHARACTERISTIC (product_id, char_id, product_char_value)

Скажите пожалуйста правильно (rjhhtrnyj) ли я составил структуру БД (как вариант) для выполнения описанных выше требований?
Возможно вы можете дать совет или что-то добавить по организации БД для выполнения описанных выше требований.
 

Igor aka TiGR

Новичок
А таблицы производителей не будет?

Почему нельзя запихать все характеристики в одну таблицу к продуктам?
 

Гриша К.

Новичок
Igor aka TiGR, спасибо за ответ.
Потому у одного товара может быть больше одной характеристики.
Вы можете написать примерную структуру БД предложенного вами варианта?

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

Igor aka TiGR

Новичок
Вы можете написать примерную структуру БД предложенного вами варианта?
Выкидываем CHARACTERISTICS и PRODUCT_CHARACTERISTIC, все характеристики пихаем в PRODUCTS. Например:

PRODUCTS (product_id, product_name, product_description, width, height, color, price, weight)
 

vonica

Новичок
Автор оригинала: Igor aka TiGR
Выкидываем CHARACTERISTICS и PRODUCT_CHARACTERISTIC, все характеристики пихаем в PRODUCTS. Например:

PRODUCTS (product_id, product_name, product_description, width, heigth, color, price, weight)
С одной стороны это упростит дальнейшую работу с базой, но в случае когда товары очень отличаются по характеристикам, да и характеристик у каждого товара порядка 10-50, а то и все 100, я думаю подход Гриша К. правильный.

Да и такой ньюанс, а если кроме веса, цвета, ширины, длины и высоты все остальные характеристики будут разные, тоесть количество полей в таблице продуктов будет не 100 (по максимальному количеству характеристик Х товара, а намного больше)

Решение зависит от специфики Вашей задачи.
 

Igor aka TiGR

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

И прежде чем решить использовать 3 таблицы вместо одной стоит хорошенько подумать - а обосновано ли это решение.
 

vonica

Новичок
Автор оригинала: Igor aka TiGR
Но наиболее часто используемые характеристики должны быть в таблице товаров. Иначе придётся при каждом запросе дёргать три таблицы вместо одной.

И прежде чем решить использовать 3 таблицы вместо одной стоит хорошенько подумать - а обосновано ли это решение.
С этим трудно не согласиться!

Но исключения тоже имеют место! Хотя и редко.:eek:
 

Гриша К.

Новичок
Igor aka TiGR, vonica спасибо за ответы.

PRODUCTS (product_id, product_name, product_description, width, heigth, color, price, weight)
Все таки думаю такой вариант не подойдет, потому что, характеристик у товаров может быть очень много, и у каждого типа товара могут быть разные типы характеристик.
Предположим что в таблицу PRODUCTS, я добавил характеристики: размер, цвет, жесткось, и имеется в БД уже 1000 товаров, дальше например размещается новый тип товара, у которого есть свои новые типы характеристик, например кресла, у которых есть тип характеристики: обивка и высота сиденья, в таком случае в существуюющую таблицу придется добовлять новые столбцы, я предполагаю что это нехороший вариант.

С одной стороны приведенная мной структура БД мне нравится, но так как я еще не имею опыта в организации структуры БД под описанные мной требования (и вообще опыт мал), я решил создать тему в топике, чтобы увидеть возможную критику или дополнения по данному решению.
Наверное есть уже рапространенный (отработанный) вариант структуры БД для данного случая, приведенная мной структура схожа с ней?
 

alexhemp

Новичок
Гриша К.

Все нормально с твоей структурой, не слушай vonica

Он не понимает зачем ты делаешь нормализацию.

Подумай только над
> Товары по производителям # PRODUCT_FIRM (product_id, firm_id)

Обычно товар имеет одного производителя, я использую понятие БРЕНД.

Но в каждой предметной области свои тонкости.
 

vonica

Новичок
alexhemp
Не слушай vonica но сделай как он пишет, так выходит по Вашему.

Почитайте внимательнее, что я писал.
 

Гриша К.

Новичок
alexhemp, спасибо за ответ.
И действительно товары по проивзодителям, а также товары по категориям, я уже решил держать все в одной таблице
PRODUCTS (product_id, cat_id, firm_id, product_name, product_description). При практической реализации я увидел что смысла в разделение нету.

А vonica вобщем-то написал что приведенная мной структура нормальная.
 

alexhemp

Новичок
Гриша К.

Я перепутал когда кликал, только щас заметил. :)
Не слушай Igor aka TiGR.

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

Гриша К.

Новичок
alexhemp, спасибо за ответ.
Вообще товар у меня может быть в одной категории.
Каетгории построены в виде дерева, и если например товар находится в категории: Орт. изделия -> Головодержатели,
то при просмотре Орт. изделий, я буду выводить товары также из всех соответсвующих подкатегорий (хотя пока возникают сложности с выводом поддерева).
 
Сверху