приветствую! 
впал в творческий ступор, требуется имерженси хелп)

таблица (Т1)  вида:
|-- ID --|-- TITLE --|

таблица Т2 вида:
|-- ID --|-- ITEM_ID --|-- OPTION_ID --|-- VALUE --|

в таблице Т1 хранятся названия элементов, Т2 - содержит набор данных для элементов Т1.

нужно выбрать все записи из Т1, которые удовлетворяют условию запроса.  
запрос  формируется на основе массива связок вида  T2.option_id=$val  

пока ничего в голову, кроме цикличного JOIN-а всех опций не приходит.. 
например у нас есть массив условий:


то запрос для него формируется следующего вида:


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

или может имеет смысл делать единую таблицу Т1 т Т2 со всеми опциями?  ( описывал тут) 

ИМХО JOIN'ы лучше не использовать, лучше через where

PS Какая-то у Вас извращенная задача стоит.

ваш запрос выведет все записи, для которых совпала ХОТЬ одна опция... 


а что в ней извращенного? 
обычный поиск  по базе данных =)

Добавьте к нему

AndreyIQ,  
таблица Т2 содержит данные такого вида:

|-- ID --|-- ITEM_ID --|---- OPTION_ID ----|----- VALUE --|
|-- 1 ---|------- 1 ------|--- (1)материал ---|--- металл --|
|-- 2 ---|------- 1 ------|--- (1)материал ---|--- карбон --|
|-- 3 ---|------- 1 ------|--- (2)давление ---|----- 2.5 -----|
|-- 4 ---|------- 1 ------|----(3)сечение ----|------- 50-----|
|-- 5 ---|------- 2 ------|--- (1)материал ---|-- пластик --|
|-- 6 ---|------- 2 ------|--- (2)давление ---|----- 2.5 -----|

а поисковый запрос:

материал='металл,алюминий',
давление=2.5

соответственно выбрать нужно все ITEM_ID  для которых выполняется условие:
материал=(метал или аллюминий) и давление=(2.5)  (в этом примере получается только ITEM_ID=1 т.к. у ITEM_ID=2 материал не удовлетворяет условию: 'металл или алюминий',

Добавлено @ 17:52

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

это я к тому а не устанет ли mysql перебирать такие объемы данных  (около миллиона записей в таблице Т1 и на каждую из них приходится в среднем 10 записейв в Т2 - тоесть 10 миллионов.  


Это сообщение отредактировал(а) z-END - 20.9.2011, 17:52

А вот это уже не твоя забота... если ему станет плохо - он скажет.

как раз тики моя))) если он будет это медленно выполнять все придется переделывать...

z-END, хватит ваньку-то валять. Вот КОГДА будет выполняться медленно - ТОГДА и будем думать над увеличением производительности. Но если ты заранее изучишь план выполнения и построишь необходимые для оптимизации индексы (с учётом наполнения и селективности) - это ТОГДА так и не наступит.

Akina, ответ достойный советского автопрома)))) 
давайте сделаем ладу-приору, а там уж если будет кривая, будем думать))))

z-END, если ты изначально намерен выпускать лады-приоры - может, задуматься о перепрофилировании завода вообще? или закрыть его к чёртовой матери?

У Вас большое кол-во OPTION_ID?

AndreyIQ, 
в базе будет хранится порядка 100 видов, для каждого вида есть свой набор опций - в среднем порядка 10 шт.  получается что option_id - будет около 1000.



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

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

приветствую вас Капитан Очевидность)
именно этот вопрос я и пытаюсь понять:

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

применительно к текущей ситуации - добавил 1.5 млн строк в Т2  и около 60 тыс в Т1.  

цифры меня шокировали... 
мой вариант:


вариант с where на 4 сек. медленней


вот структура таблиц:
Т1


Т2


Профилирование дает приблизительно такой результат: 

Хотелось бы еще план увидеть