Здравствуйте, strelochnik, Вы писали:
S>Спасибо. Проблема в том, что перед тем как выполнять запрос, нужно вычислить эту самую detailsTable (ProductsTVAttribs, ProductsTVAttribs...) по CategoryID
Если тебе нужна таблица по всем товарам и всем значениям атрибутов которые у них есть, то конечно да. Но, прости, не понимаю зачем тебе такая таблица? Количество столбцов в ней будет равно сумме количеств всех типов атрибутов у всех типов товаров — это же кошмар как много. Обычно же, в магазине выбираешь категорию и тебе выводят таблицу с параметрами данной категории. Или я ищу товары, а мне в результирующем списке выводят список основных параметров со ссылками на страницы с полной детализацией. :-) Да и для ввода в поиске значений спец-параметров, надо всёравно генерить поля ввода...
Ну м.б. надо сделать выборку (Имя, Тип, Атрибуты), где Атрибуты="атрибут_имя_1=значение; ...; атрибут_имя_N=значение" тогда EAV прощще.
S>положить ее в переменную, и эту переменную каким-то образом использовать в вышеприведенном запросе — вот я и сомневаюсь, что такое возможно средствами sql :xz:
Есть таблица категорий, человек выбирает из списка интересующую категорию, ID-этой категории определяет какой хранимкой получить список товаров с их параметрами, легко написать генератор таких хранимок. В сущности отличие только в том с какой таблицей сделать INNER JOIN.
S>Т.е. при таком подходе уж очень неудобно выковыривать данные. Пожалуй, паттерн EAV, который посоветовал Flying Dutchman — то что нужно. Попробую его внедрить )
Если объёмы не большие, то всё будет работать нормально. Я не спорю, просто я никогда не считал что сложность БД определяется количеством таблиц, неумелыми руками можно и 10 таблиц превратить в кашу.
Наука изощряет ум; ученье вострит память.
(c) Козьма Прутков