Динамические параметры товаров – как правильнее хранить?

[Foshvad]

Динамические параметры товаров – как правильнее хранить?

Есть магазин в котором продаются различные товары – от монитора до книги.
У товаров есть базовый набор атрибутов (название, цена, статус), а есть и динамические. Для мониторов, например, – размер диагонали, максимальное разрешение и т.п. У книг – автор и ISBN

Вопрос в том, как хранить дополнительные параметры.
Вариант с дополнительной таблицей вида

id_товара | название параметра | значение параметра


всем подходит, если бы не одно «но»

Тип поля «значение параметра» должен быть VARCHAR. Но как тогда быть с сортировкой по полям, которые принимают только числовые значения? Например количество страниц в книге. Или если значения – даты, как быть с функциями для дат, например DAYOFYEAR?

Спасибо.

 

[neko]

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

 

[HEm]

скажем, у меня 300-500 категорий товаров, ты предлагаешь создать 300-500 таблиц? для магазина в 7-10 тысяч наименований товаров?

-~{}~ 14.06.04 12:03:

Foshvad
хорошее, но ресурсоемкое решение - XML
а вообще покопай по форуму, обсуждалось

 

[neko]

HEm

не вижу никаких препятствий

-~{}~ 14.06.04 12:08:

это все верно при условии что дополнительные параметры существуют для некой категории, а не для конкретного товара в категории

 

[Yaguan]

дополнительные параметры разных типов хранить в разных таблицах. В одной - varchar, в другой - int etc.

 

[Oleg Marchuk]

Foshvad
В чем проблема для цифровых переметров создать отдельную таблицу?

 

[Foshvad]

HEm

скажем, у меня 300-500 категорий товаров, ты предлагаешь создать 300-500 таблиц? для магазина в 7-10 тысяч наименований товаров?

Согласен.
При этом для сводной статистики по всем товаром все эти 300 таблиц прийдется объединять.

а вообще покопай по форуму, обсуждалось

Обыскался все и вся - никаким конкретных решения не нашел (нужен не код, а хотя бы сам принцип)
Если видел - можешь пару ссылок запостить?

-~{}~ 14.06.04 12:16:

Yaguan
Для дат - третью, для decimial - четвертую?


А будет ли заведомо нерациональным применение таблицы подобной структуры:

id_товара | название параметра | значение числового параметра | значение текстового параметра | значение даты- параметра

 

[neko]

вот изобретатель, а

делаешь таблицу для мониторов
id | цена | модель | диагональ | итд | итп

делаешь таблицу для книг
id | цена | автор | кол-во страниц | итд | итп

делаешь еще одну таблицу
название столбца | тип данных
чтобы знать что выбирать и как выводить

-~{}~ 14.06.04 12:21:

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

 

[HEm]

Автор оригинала: Foshvad
Обыскался все и вся - никаким конкретных решения не нашел (нужен не код, а хотя бы сам принцип)
Если видел - можешь пару ссылок запостить?

Влом искать
ну, например http://phpclub.ru/talk/search.php?s=&action=showresults&searchid=275371&sortby=lastpost&sortorder=descending

А будет ли заведомо нерациональным применение таблицы подобной структуры:

id_товара | название параметра | значение числового параметра | значение текстового параметра | значение даты- параметра

Вот я тоже склоняюсь к такой структуре

 

[neko]

HEm

т.е. ты предлагаешь каждый раз чтобы просто вывести какой-то конкретный товар, сначала сделать селект из основной таблицы, а потом селект из этой с доп. свойствами?

кстати вот при этих нереальных объемах категорий которые ты указал как ты собираешься разносить данные по дискам например?

-~{}~ 14.06.04 12:30:

а также меня черевычайно интересует вопрос как ты при такой собираешься искать товар в пределах категории по "дополнительным" свойствам

 

[Yaguan]

А будет ли заведомо нерациональным применение таблицы подобной структуры:

id_товара | название параметра | значение числового параметра | значение текстового параметра | значение даты- параметра

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

 

[Foshvad]

HEm

Влом искать
ну, например http://phpclub.ru/talk/search.php?s...rder=descending

Вопрос исчерпан.
YEAR(текстовое-поле) позвращает то, что надо

Остался один вопрос:


если в текстовых полях будет что-то вроде

1
10
120
2
20

можно MySQL заставить при сортировке трактовать их как числовые, а не текстовые? (тип поля varchar)

чтоб получилось


1
2
10
20
120

 

[HEm]

neko
с чего ты взял, что нереальные? у меня например в настоящий момент каталог фирмы, торгует: бытовой и орг.техникой, фото, аудио-видео, телефония, торговое оборудование
категорий трех уровней - 615 штук (на верхнем - 6 штук)
и это в регионе, для сайта московской фирмы или всероссийской может быть и еще больше

Автор оригинала: Yaguan
Но здесь неизбежно большое количество пустых полей, что не есть признак удачного проектирования базы...

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

 

[IntenT]

Foshvad

Тип поля «значение параметра» должен быть VARCHAR. Но как тогда быть с сортировкой по полям, которые принимают только числовые значения? Например количество страниц в книге. Или если значения – даты, как быть с функциями для дат, например DAYOFYEAR

в чем проблема взять и проверить, работают ли эти функции на полях типа варчар. так вот, они работают (с оговоркой, что данные валидные). И сортировка работает.

 

[neko]

разница между 600та и 10ю тысячами тебе конечно неизвестна

 

[Foshvad]

IntenT

в чем проблема взять и проверить, работают ли эти функции на полях типа варчар. так вот, они работают (с оговоркой, что данные валидные). И сортировка работает.

Проверил - с датой все нормельно, но по числовые данные сортирует как текст (логично, ведь тип поля varchar)

А надо для конкретных выборок указать, что данные трактовать как числа, а не текст. Если кто знает как - скажите.

 

[IntenT]

можно MySQL заставить при сортировке трактовать их как числовые, а не текстовые? (тип поля varchar)

чтоб получилось


1
2
10
20
120

SELECT * , value+0 AS num FROM tbl ORDER BY num

 

[HEm]

neko
я не понял, 300-500 - "нереальные объемы", а 10 000 - это откуда?

 

[neko]

неоткуда, невнимательно прочел

решение тем не менее идиотское...
делайте впрочем как хотите

 

[Foshvad]

IntenT

SELECT * , value+0 AS num FROM tbl ORDER BY num

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