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

Назначение таблиц
Table_catalog – таблица с категориями товаров (parent используется как отношение подгруп к группам)
Table_product – таблица с товарами
table_property – свойства номенклатуры задается категории и действует на все вложенные товары
(тип 0 – выбирается из списка 1-имеет конкретное значение 2- да\нет)
table_catalog_to_property - какие своиства товаров будут у данной категории
table_group_param – группировка свойств номенклатуры (то есть какие значения может принимать данное свойство если тип свойства стоит 0)
table_product_property_value – табличка с значениями свойств конкретного товара

если type = 0 то значение value является индификатором в таблице table_group_param откуда и вытащить значение номенклатуры у товара
если type = 1 или 2 то либо вытащить значение прямо с поля value или обратиться в другую таблицу, данный момент более детально не рассмотрел.
Вот в принципе и все, жду комментариев.

Подход к задаче утопичен по определению.


Три раза прочитал, но смысл не осилил.



Есть: Категория1 => Категория2 => ... КатегорияN => Товар.

table_ - префикс выбрали, чтобы было понятно что не растровые изображения в каталоге СУБД находятся?

Жаль что не рассмотрели. Потому как если вы будете выводить товары одним списком то для части товаров у вас буду одним джоины, для другой части другие а для третьей могут и не понадобиться.

Структура в зависимости от задач (читать выше про реалистичность универсальных каталогов) может изменяться, но в целом будет содержать:

1. Рубрики.
2. Товары.
3. Дополнительные свойства рубрик.
4. Значения дополнительных свойств.

Связи проработать не сложно. Важно не забыть что:

1. Скорее всего дополнительные свойства (поля) будут требоваться разного типа. В Бд их можно хранить, как строки, но сами значения могут различаться и их будет не только 2 вида.
(Селекты, мультиселекты, чекбоксы, строковые знечения, числа, текст). Они не обязательно привязаны к html-интерпратации этих полей, но создают основания для создания отдельных типов свойств с целью унификации проверки и хранения их значений.

2. Скорее всего вам потребуются структуры дополнительных полей, подобные структурам рубрик (мать->дочка)

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

4. Скорее всего дополнительное свойтсво может быть общим для нескольких рубрик.

5. Скорее всего свойства могут быть обязательными или необязательными

6. Скорее всего потребуется особый тип дополнительных свойств не хранящих значений, а служащей для логической группировки (fieldset).

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

не структура каталога будет работать и работает на одной таблице table_catalog вот пример (вывод в администрировании)
(Добавление)
по порядку
1 В курсе данного вопроса поэтому в свойствах добавлен тип
2 Структура есть
3 пока не рассматриваю валидацию
4 в том и суть что каждой рубрике я могу добавить хоть все свойства которые созданы
5 естественно можно добавить это в таблицу table_catalog_to_property для того чтобы можно было ставить для одной группы это свойство обязательное для другой нет
6 не понял для чего
7 скорее всего но их мало (цена например)

по вопросу по префиксу table_ выбрал просто чтобы каталог отделить визуально в структуре от еще пол сотни таблиц в проекте
(Добавление)
(сразу оговорюсь что для вывода будет использоваться подготовленная страница которая будет сформирована при заведении номенклатуры то есть практически без запросов в базу) данная структура сделана для удобства администрирования.

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

на так и назови префикс catalog_ или типа того
table_ говорит о том что все остальные - не таблицы

нашли к чему подкопаться исправлю, вобще меня интересовала сама идея реализации нормально или как?

Я вас понял. Бегите от такой реализации и никогда не используйте её в тех проектах, которые вы указали. Игра не будет стоить свеч ни для интернет-магазина ни для каталога недвижимости и лучше хранения данных, а не готовых html и иных кэшей нод, решения не будет.
Почему?
1. Аксессуары товара
2. Похожие объявления недвижимости
... дальше продолжать?
Как обновлять эти связи будете? включить в эти же кэши, хранимые в базе или делать такие же джоины других кэшей?

Ваша реализация будет целесообразна только в том случае, если на одной странице у вас одна нода. Вы в контроллере обработаете айдишник и гордо покажете данные товара юзеру не дёргая бд джоинами свойств товара.
А какой это потребует обвязки при редактировании? При связях с аксессуарами и их изменении и вообще при изменении любых связей?
И для чего будет выигрыш в производительности? для блока отображения одного товара или объявления? Его не будет.

обсуждалось недавно. Стандартный EAV.

http://forum.php.su/topic.php?fo...8&topic=5211

Хранить готовые страницы - чушь. В этом нет никакого смысла,не говоря уже про лишние хлопоты с реализацией.

Единственный, как я уже говорил оправданный вариант, — хранение и представление одной сложной ноды, которая редко редактируется, по которой не ведется поиск и у которой нет используемых внешних связей.
При работе с деревьями и любыми данными со структурами сложнее чем группа->элемент про такой подход друпаловский (хранит он так как раз такие ноды в базе) лучше забыть.

ну почему же так все прям плохо, об этом я тоже думал, блок связей отдельно будет грузиться (сопутствующие товары) (кешироваться) будет кусок где находятся свойства товара или как вы предлагаете делать при выводе кучу запросов в базу чтобы вытащить все эти свойства (может можно при такой реализации вытащить все и одним запросом но в запросах при реализации на ПДО до такого я пока не "дорос" к сожалению)

синтаксис запросов не зависит от того ПДО это или нет.
и какая там куча запросов? на страницу выводится обычно пару десятков товаров максимум

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

понял, "кешировать" не буду.
А про ПДО я говорил так как столкнулся с небольшой проблемой в фильтрации когда неизвестно будет какой то параметр участвовать в фильтре или нет, если будет его необходимо подготовить "BindParam" а если нет, или заранее неизвестно количество элементов фильтра. Я про это говорил

Сделайте голые запросы чтобы работало, потом обернёте в любую обёртку, как подучите по ней маны. Хоть пдо хоть не пдо.

Спасибо всем за участие!

Их не просто мало... . Позже вы прийдете к необходимости замещения базовых полей дополнительными свойствами товара.
например для одной записи у вас будет извлекаться базовое поле "Цена"
А для другой записи у вас вместо базового поля будут использоваться дополнительные свойства, объединённые общим лейблом:

Цена:
1. Цена за 1 мес.
2. Цена за 6 мес.
3. Цена за год.
4. Цена продажи.

5. Оптовая цена
6. Цена со скидкой ...

Аналогично, если говорить о недвижимости с базовым полем всех объектов "Площадь".