Цитата:вобщем пытаюсь сделать универсальный.
Подход к задаче утопичен по определению.
Цитата:(сразу оговорюсь что для вывода будет использоваться подготовленная страница которая будет сформирована при заведении номенклатуры то есть практически без запросов в базу) данная структура сделана для удобства администрирования.
Три раза прочитал, но смысл не осилил.
Цитата:Если есть какието варианты обще принятые то хотелось бы посмотреть и их, к сожалению я не нашел.
Есть: Категория1 => Категория2 => ... КатегорияN => Товар.
table_ - префикс выбрали, чтобы было понятно что не растровые изображения в каталоге СУБД находятся?
Цитата:
если type = 0 то значение value является индификатором в таблице table_group_param откуда и вытащить значение номенклатуры у товара
если type = 1 или 2 то либо вытащить значение прямо с поля value или обратиться в другую таблицу, данный момент более детально не рассмотрел.
Жаль что не рассмотрели. Потому как если вы будете выводить товары одним списком то для части товаров у вас буду одним джоины, для другой части другие а для третьей могут и не понадобиться.
Структура в зависимости от задач (читать выше про реалистичность универсальных каталогов) может изменяться, но в целом будет содержать:
1. Рубрики.
2. Товары.
3. Дополнительные свойства рубрик.
4. Значения дополнительных свойств.
Связи проработать не сложно. Важно не забыть что:
1. Скорее всего дополнительные свойства (поля) будут требоваться разного типа. В Бд их можно хранить, как строки, но сами значения могут различаться и их будет не только 2 вида.
(Селекты, мультиселекты, чекбоксы, строковые знечения, числа, текст). Они не обязательно привязаны к html-интерпратации этих полей, но создают основания для создания отдельных типов свойств с целью унификации проверки и хранения их значений.
2. Скорее всего вам потребуются структуры дополнительных полей, подобные структурам рубрик (мать->дочка)
3. Скорее всего вам потребуется валидация значений определённых типов дополнительных свойств
4. Скорее всего дополнительное свойтсво может быть общим для нескольких рубрик.
5. Скорее всего свойства могут быть обязательными или необязательными
6. Скорее всего потребуется особый тип дополнительных свойств не хранящих значений, а служащей для логической группировки (fieldset).
7. Скорее всего будет некий набор базовых свойств, которых можно включить в таблицу товаров и для некоторых шаблонов будет достаточен этот набор свойств без дополнительных джоинов. (Отредактировано автором: 12 Ноября, 2013 - 12:53:57)
|