Структура данных, mysql

[Cris]

Как организовать таблицы в базе данных чтобы хранить товары как в hotline с разным набором параметров по категориям? уже была мысль для каждой категории создавать по таблица, хотя не хотелось бы плодить таблицы, вторая мысль создать таблицу с 20-ю столбиками под параметры но это глупо.
и как организовтаь поиск по товарам как на хотлайне?, т.е. выбираем категорию и потом возле каждого параметра будет в скобках будет написано сколько с таким параметром товаров останется... делать запрос под каждый параметр и узнавать?

такого как: хранить товары в виде сериализированого обьекта, потом выбирать все из базы и уже скриптом сортить, выбирать..., не предлагать

 

[Тарас]

Как организовать таблицы в базе данных чтобы хранить товары как в hotline с разным набором параметров по категориям? уже была мысль для каждой категории создавать по таблица, хотя не хотелось бы плодить таблицы, вторая мысль создать таблицу с 20-ю столбиками под параметры но это глупо.
и как организовтаь поиск по товарам как на хотлайне?, т.е. выбираем категорию и потом возле каждого параметра будет в скобках будет написано сколько с таким параметром товаров останется... делать запрос под каждый параметр и узнавать?

такого как: хранить товары в виде сериализированого обьекта, потом выбирать все из базы и уже скриптом сортить, выбирать..., не предлагать

Как организовать таблицы в базе данных чтобы хранить товары как в hotline с разным набором параметров по категориям?

сделай иерархическую структуру таблиц. во главе например табличка с полями айди и цена, айди сделай ключевым и через него привязывай таблицы с разными категориями товаров . Ты пишешь глупо плодить таблицы , глупее делать все в 1й таблице.

и как организовтаь поиск по товарам как на хотлайне?

запросы + счетчик который подсчитывает подходящие позиции

делать запрос под каждый параметр и узнавать?

не совсем понял , делать запрос под каждый параметр не нужно , делай 1н запрос но с многими параметрами

 

[Dre.hz]

hotline = hotline.ua? То есть речь идет о хранении дерева? Все очень просто. Прочитай вот эту статью - там описан способ хранения самой иерархической структуры (в твоем случае - дерево категорий).

You must be registered for see links

(Preorder Tree Traversal).

Таким образом категории хранятся в одной отдельной таблице.

Далее, продукты - просто таблицей (products_id, title, ...). Один продукт может быть в нескольких категориях? Если нет, то в таблице продуктов еще поле categories_id. Если же да, то это отношение "многие ко многим" - делаешь таблицу products_to_categories с полями products_id, categories_id (и unique index на эту пару полей), и в ней хранишь пары продукт-категория.

С sql запросами помощь нужна или сам разберешься?

 

[Dre.hz]

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

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

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

Конкренто здесь, несколько одинаковых таблиц для хранения категорий - верх непрофессионализма.

 

[Cris]

Я понял что вопрос задал не корректно, очень. Глупо я писал - делать 1 таблицу с 20-ю полями.
вот у меня есть Товар 1, Товар 2
у Товар 1 есть параметры: ИД, КОД в базе, цена, ширина, длинна, вес
у Товар 2 такие параметры: ИД, КОД в базе, цена, цвет, материал

как мне сделать чтобы я создал 2 категории, одну для для товаров с параметрами такимиже как и у Товар 2, и вторую категорию соответствено с параметрами как у Товар 2.
как это наиболие удобно хранить + чтобы запросы для каждой категории можно было делать по любым параметрам и в любом количестве, категорий таких будет до от 20 штук, делать дополнительные таблицы которые расширяют стандратную для товара?
тоесть будет таблица Товары: ИД, КОД в базе, цена, и будет еше 2 - Товары категория 1, Товары категория 2, с соответственными дополнительными параметрами и ИД записи, ИД товара в первой таблице. с запросами я разберусь
и второй вопрос
на текущий момент я отображаю категорию 1
мне нужно чтобы в блоке с фильтрами в скобках возле каждого фильтра было написано "сколько товаров останется/прибавится/убавится" если применить этот фильтр

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

 

[Тарас]

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

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

Конкренто здесь, несколько одинаковых таблиц для хранения категорий - верх непрофессионализма.

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

 

[Dre.hz]

Cris, смотри. Создаешь таблицу категорий, так как я написал.

Далее создаешь таблицу с параметрми товара parameters (parameters_id, name, type?) - где ты перечисляешь всевозможные параметры. Все в рамках твой системы (ширина, длина, вес, материал, и.т.д). Затем таблицу-связку categories_to_parameters (categories_id, parameters_id - и эта пара полей unique_index). И у тебя готова структура, которая позвляет привязвть к конкретной категории набор параметров. Дальше таблица products_to_parameters (products_id, parameters_id, value) с набором конкретных значений.


Далее тебе надо отфильтровать все товары с длиной Х.

SELECT pr.*
FROM products_to_parameters pr2pa
LEFT JOIN parameters pa USING (parameters_id)
LEFT JOIN products pr USING (products_id)
WHERE pa.name='Длина' AND pr2pa.value=X


Если ты хочешь иметь возможность хранить квантированные значения - имеет смысл пойти дальше и сделать еще одну таблицу для всевозможных предустановленных значений полей (например - производители): parameters_values (parameters_id, value) - отсюда легко выбрать набор значений для такого-то параметра.

 

[Cris]

Cris, смотри. Создаешь таблицу категорий, так как я написал.

Далее создаешь таблицу с параметрми товара parameters (parameters_id, name, type?) - где ты перечисляешь всевозможные параметры. Все в рамках твой системы (ширина, длина, вес, материал, и.т.д). Затем таблицу-связку categories_to_parameters (categories_id, parameters_id - и эта пара полей unique_index). И у тебя готова структура, которая позвляет привязвть к конкретной категории набор параметров. Дальше таблица products_to_parameters (products_id, parameters_id, value) с набором конкретных значений.


Далее тебе надо отфильтровать все товары с длиной Х.

SELECT pr.*
FROM products_to_parameters pr2pa
LEFT JOIN parameters pa USING (parameters_id)
LEFT JOIN products pr USING (products_id)
WHERE pa.name='Длина' AND pr2pa.value=X


Если ты хочешь иметь возможность хранить квантированные значения - имеет смысл пойти дальше и сделать еще одну таблицу для всевозможных предустановленных значений полей (например - производители): parameters_values (parameters_id, value) - отсюда легко выбрать набор значений для такого-то параметра.

хм.. да не плохо, спасибо.
что-то до меня не дошло связать все много-к-много
-----------------------
на счет хранения дерева в базе, мне надо было хранить меню, причем легко совершать такие запросы: найти все товары этого меню и всех его подменю, найти всех родителей - т.е путь к корню, ну и так дальше, и на это я нашол NestedSets - очень удобная штука

 

[Dre.hz]

Вот список таблиц с ключевыми полями.

products
products_id
name
price
...


categories
categories_id
name
parent_categories_id
...


products_to_categories
products_id (foreign key to products.products_id)
categories_id (foreign key to categories.categories_id)


parameters
parameters_id
name


parameters_to_categories
parameters_id (foreign key to parameters.parameters_id)
categories_id (foreign key to categories.categories_id)


values
values_id
parameters_id (foreign key to parameters.parameters_id)


products_parameters_values
products_id (foreign key to products.products_id)
parameters_id (foreign key to parameters.parameters_id)
values_id (foreign key to values.values_id) (NULL)
value - если values_id=NULL, то здесь можно установить неквантируемое значение.


Вроде ничего не упустил. Если что - подредактирую этот пост.