Здравствуйте, форумчане sql.ru! Есть у меня задачка. Чтобы не рассредоточивать внимания на несущественное, несколько упрощу ситуацию, отброшу всё лишнее. Есть две таблицы: DATA (главная) и VALUES (подчинённая). Структура таблицы DATA:

Int Vehicle, /*Номер марки автомобиля*/
Int Property /*Номер характеристики*/

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

Int Vehicle, /*Номер марки автомобиля*/
Int Property, /*Номер характеристики*/
Int Index, /*Номер значения характеристики для данных Vehicle и Property */
DOUBLE MINVALUE, /*Нижнее значение интервала-значения характеристики */
DOUBLE MAXVALUE /*Верхнее значение интервала-значения характеристики*/

Поля Vehicle, Property и Index являются составным первичным ключом. Как я уже писал, они связаны с соответствующими полями в главной таблице. Т.е. пусть есть автомобиль марки с номером Vehicle. Если у него есть характеристики, то узнать какие они можно из таблицы DATA. Так как характеристики могут состоять из нескольких интервальных значений, то нужно обратиться к таблице VALUES и выбрать все записи с нужными значениями в полях Vehicle и Property. Если характеристика не интервальная, а точечная, то MINVALUE = MAXVALUE. В целом же, MINVALUE <= MAXVALUE.

Теперь собственно моё затруднение. Пользователь может формировать запросы со многими условиями (а я формирую их динамически в коде программы). Например, найти все модели автомобилей не дороже $15000 ИЛИ мощностью двигателя не менее 140 л.с. (обратите внимание на соединение условий с помощью слова «ИЛИ») – нет никаких затруднений:

SELECT VEHICLE FROM VALUES WHERE
( (PROPERTY = 11) AND (MAXVALUE <= 15000) ) OR ( (PROPERTY = 2) AND (MINVALUE >= 140) )

А вот пример другого запроса: найти все модели автомобилей не дороже $15000 И мощностью двигателя не менее 140 л.с. (обратите внимание на слово «И»). Вот тут-то и возник вопрос: а как найти эти записи? Дело в том, что от меня требуется сделать такую поисковую систему, которая позволяла бы пользователю формировать достаточно сложные запросы: чтобы он мог составить условие, скажем, по пяти разным характеристикам с использованием связок «И», «ИЛИ». Т.е. я хочу сказать, что заранее неизвестно число подусловий (если так можно сказать, т.е. элементарных условий) и какие логические операторы и сколько их (в смысле, сколько «И», а сколько «ИЛИ», понятно общее число их известно и они взаимосвязаны) будут использованы.

Как вариант – выполнять поиск по каждому элементарному условию, сохранять результаты в программе, а потом уже работать со списками и обрабатывать то, что получилось с помощью логических операторов. Т.е. для пяти элементарных запросов я создаю пять списков и выполняю эти пять элементарных запросов с занесением информации в соответствующие списки. Затем я смотрю на логические операторы между элементарными условиями и программно (не в SQL) получаю результирующий список путём объединения/нахождения общих элементов в пяти списков в соответствии с логическими операторами и последовательностями действий. В этом варианте мне не нравится то, что придётся для каждого элементарного условия заново производить поиск, ну и то, что какое-то из условий может совсем незначительно сузить полное множество марок автомобилей и мне в одном из подзапросов вернутся практически все записи из таблицы автомобилей.

Или это нормальный вариант? Если нет, то какие возможны альтернативы?

P.S. Может я зациклился сегодня уже на этом вопросе и он элементарен? В голову лезут всякие подзапросы (но мне кажется, что это будет или медленно или … не знаю, такое чувство, что произвольное число условий где-нибудь выйдет боком). В принципе, их может быть действительно много (марок автомобилей).

P.P.S. Произвольное число условий – это произвольное число, но РАЗУМНОЕ, т.е. небольшое (думаю уж всяко <= 10). СУБД – Firebird 1.5.3.

Спасибо за внимание к задаче (и за мозговой штурм )! Вроде что-то вырисовывается – пока не буду писать - сегодня обдумаю и завтра попробую реализовать, позже опишу результаты.

Теперь отвечу на предыдущие сообщения, а в конце задам ВОПРОС, родившийся по ходу чтения обсуждения:

-----------------------------------------------------------------

2 ModelR в ответ на вопрос:

И что будет означать

Vehicle Property Index MINVALUE MAXVALUE
Модель1 Масса 1 4000 4000
Модель1 Масса 2 6000 6000

Я понял, что Вы имеете в виду. В приведённом Вами примере не нужно хранить две записи (т.е. для характеристики «масса»). Конечно, в этом случае будет только одна запись с Index = 1 (или 0, но, опять же, одна запись). Просто есть такие характеристики, у которых может быть несколько возможных значений: например, в разных режимах езды (город/скоростное шоссе) различный расход топлива. Т.е. характеристика одна (расход топлива), а значения два. Чтобы предупредить дальнейшие вопросы, я повторю, что я упростил задачу и саму структуру таблиц и оставил только самое существенное, в моей программе учитываются и режимы и другие особенности. Мне показалось логичным не перегружать задачу деталями.

2 sti: Откровенно говоря, 10 вариантов я вряд ли осилю (это ж вроде (512 + 256 +128 +64 + 32 + 16 + 8 + 4 + 2) = (1024 – 2) вариантов различных запросов; даже если оптимизировать по перестановкам, то всё равно много), хотя если будет вызывать слишком большие с точки зрения пользователей задержки, и этого числа будет много, то попробую уменьшить максимальное число одновременных условий и сформировать заранее. Надо всё-таки попробовать и то и другое, хотя бы на паре-тройке разных запросов (и по сложности тоже).

2 gardenman: С XQuery я не знаком. Посмотрю, что это такое, но, боюсь, это не подойдёт, если нельзя искать по XML-данным. Искать в том смысле, что вряд ли удастся выделить самые ходовые, так как есть разные категории пользователей и, соответственно, им нужны различные характеристики при работе. Таким образом, если это принципиально, то вроде бы не очень подходит. Но раз уж взялся за такое дело, то надо посмотреть, что такое XQuery и с чем его едят.

2 ModelR и rgb-dart: Ваши варианты мне понятны. С двумя псевдонимами вроде как быстро будет работать, но насколько эффективно это будет в случае 5-7 условий (самый сложный случай, когда все «И» и ни одного «ИЛИ»)? Запрос будет достаточно простой в смысле синтаксиса и мне это нравится. Что касается варианта с подзапросом, то это натолкнуло меня на один вариант, его я и хочу обдумать.

-----------------------------------------------------------------

ВОПРОС: Некоторые книги по реляционным базам данных не рекомендуют в одном запросе использовать больше 3-5 таблиц. Условие в моей задаче может содержать 10 элементарных условий (смотрите первое сообщение в теме). По сути, все значения характеристик содержатся в одной таблице. Не выродится ли, в конечном счете, сложное условие к такому запросу, который приведёт к упомянутой проблеме обращения к большому количеству таблиц? Я имею в виду, конечно, не сами таблицы, а соединения, которые стоят за этой проблемой.

2 iscrafm: Я вот не совсем понял, а можно написать последовательно (со скобками, как в Вашем условии WHERE) десяток подзапросов (будет десять WHERE с SELECT’ами)? Т.е. я хочу, чтобы они выполнились именно в порядке, начиная с "самого внутреннего" и не использовали лишние соединения. Вроде как сервер будет создавать в памяти псевдотаблицу и с ней работать. Только сделать это нужно будет десять раз подряд. Потянет Firebird 1.5.3 это? И нет ли ограничения на длину строки (в символах) запроса?

Т.е. сможет ли сервер так обработать строку этого одного достаточно сложного по вложенности запроса так, чтобы выполнить эти действия как будто бы используется 10 различных запросов, а результаты заносятся во временную таблицу. Ну, берём самый внутренний запрос (он же, понятно, будет первым условием), выполняем, получаем результаты (ключевые поля) и тут же заносим их во временную таблицу. Далее, берём следующее условие поиска, выполняем его, а полученные результаты объединяем/находим пересечение с записями из временной таблицы, тем самым, получая новую таблицу и сохраняя её вместо предыдущей. И так до тех пор, пока не кончатся условия. Только всё это делается в памяти сервера (по возможности, конечно).

ПОДВОДЯ ИТОГ: В общем, вопрос состоит в том, поймёт ли сервер, что выполнять нужно последовательно, как будто это десять запросов. Или всё-таки сделать это в коде программы (самому хранить список ключевых полей) или, как вариант, действительно создать временную таблицу и в неё заносить промежуточные данные? Есть принципиальные возражения? На практике я завтра проверю, написав подобный запрос, но пока что данных у меня не много и при имеющейся линейной зависимости от размера таблицы я могу получить бомбу замедленного действия, которая проявит себя во время эксплуатации программы.

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

Кстати, в Firebird последний вариант на практике не вызвал каких-либо осложнений - какие только запросы не строил (сначала руками, потом уже и автоматом из программы) - быстро, даже очень быстро. Скоро реализую автоматический поиск для совместных "и" + "или", но, наверное, если не всё будет гладко (а ещё ведь нужно учесть порядок выполнения операторов - по отдельности для одинаковых это было неважно, но теперь...), буду хранить промежуточные данные в спец. таблице или в памяти программы. По отдельности "И", "ИЛИ" работают очень быстро. Было б неплохо сказать Firebird: я хочу создать виртуальную таблицу в памяти и с ней работать, чтобы хранить промежуточные запросы, а потом я очищу её. Нет ли такого варианта? Я выберу нужные ключевые поля и занесу их в эту таблицу, а в следующем запросе сошлюсь на них, как на обычную таблицу. Это же, наверное, быстро будет для коротких ключей (int)? После поиска я удалю все записи из виртуальной таблицы. Можно ли тут как-то ускорить работу с обычной таблицей в этом случае?