Многокритериальный поиск

← →
databaser (2007-03-09 21:23) [0]

Есть порядка 10+ критериев поиска информации в БД. Таблиц порядка 9, много связей. Структуру пока не привожу, может и не понадобится.

Ранее я использовал TADOQuery и генерировал запрос в динамике (хранил targets / sources / conditions в массивах + рекурсия. запрос делал в виде SELECT * FROM Table1 WHERE ID IN (SELECT ... 1критерий WHERE ID IN (SELECT ... 2критерий WHERE ID IN (...)) - уж не знаю насколько правильный подход, в БД не силен.

Теперь же я перешел на хранение запросов непосредственно в mdb. Понятное дело использую параметризированные запросы. Но в итоге столкнулся с тем (мастера начинают вежливо хихикать), что пришлось делать batch создание... ну тут немного комбинаторики... в общем создание порядка 100 запросов.

Мне кажется это не особо разумным. Есть ли иные выходы из ситуации?

← →
Sam Stone © (2007-03-10 00:01) [1]

вот тут как раз и нужна структура бд. На пальцах не поймешь чего ты там в рекурсии насобирал.

← →
MsGuns © (2007-03-10 00:03) [2]

>Есть ли иные выходы из ситуации?

Объяснить пользователям основы SQL или научить пользоваться мастерами в самом акцесе

← →
databaser (2007-03-10 07:25) [3]

MsGuns © (10.03.07 00:03) [2]
Отпадает сразу. Конечный пользователь не является оператором среды MS Access и даже может не иметь его установленным на машине. Но как иной выход "засчитываю" ) Еще варианты?

Sam Stone © (10.03.07 00:01) [1]
Сложности со снятием дампа структуры с этой базы возникли. Причину так и не понял. К сожалению от руки и самое важное.

cTable(cID, ...);
AdTable(AdID, cID, ..., s);
pTable(pID, AdID, cID, ..., o);
oTable(oID, ...);
rTable(rID, cID, AdID, ..., ru);
ruTable(ruID, ...);
sTable(sID, ...);

Пример поиска - получить все cID, для которых верно (ruTable.SomeField Like "%1%") AND (sTable.SomeField Like "%2%") AND (pTable.SomeField Like "%3%"). Понятное дело используется INNER JOIN для "состыковки" по индексам, я лишь привел пример поиска по трем критериям.

← →
MsGuns © (2007-03-10 14:06) [4]

>databaser (10.03.07 07:25) [3]
>Еще варианты?

Какие могут быть варианты, если приводится какая-то задача гиперабстрактного поиска на гипервиртуальных данных.

Любая "нормальная" БД описывает ОБЪЕКТЫ РЕАЛЬНОЙ ЖИЗНИ, имеющие определенные СВОЙСТВА. И поиск, собственно, являются лишь средством обнаружения и отображения объектов, имеющих определенные (заданные) свойства.
От этого и надо плясать. Если же ваш "объект" сидит на 9 таблицах, связанных между собою целой алгеброй, то "ошибка в консерватории"

← →
Anatoly Podgoretsky © (2007-03-10 16:52) [5]

> MsGuns (10.03.2007 14:06:04) [4]

Квадратный конь в ваккуме
"MsGuns" <msguns@ukr.net> wrote in message
news:1173464588.4@delphimaster.ru...
MsGuns © (10.03.2007 14:06) [4]
>databaser (10.03.07 07:25) [3]
>Еще варианты?

Какие могут быть варианты,
если приводится какая-то
задача гиперабстрактного
поиска на
гипервиртуальных данных.

Любая "нормальная" БД
описывает ОБЪЕКТЫ
РЕАЛЬНОЙ ЖИЗНИ, имеющие
определенные СВОЙСТВА. И
поиск, собственно,
являются лишь средством
обнаружения и отображения
объектов, имеющих
определенные (заданные)
свойства.
От этого и надо плясать.
Если же ваш "объект" сидит
на 9 таблицах, связанных
между собою целой
алгеброй, то "ошибка в
консерватории"

← →
Desdechado © (2007-03-10 18:27) [6]

MsGuns © (10.03.07 14:06) [4]
+1

Все запросы и поиски имеют реальное отображение на задачи из предметной области. А комбинаторные поиски по БД вряд ли имеют смысл в реальной жизни, не считая специфических задач, для которых есть вполне формальная постановка, а не "хочу найти все, что ищется".

← →
databaser (2007-03-10 22:25) [7]

Могу пояснить более подробно.

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

Это реальное отображение на предметной области. БД проектировал в ERWin"e, потом генерировал.

Пример комбинаторного поиска: ищем по улице + категории + сайту, к примеру. Т.к. база не малая, то значимость фильтрации данных для выделения необходимой информации конечному пользователю на прямую зависит от указанных критериев.

Помогите разобраться. Я интуитивно чувствую, что "родил монстра".

MsGuns © (10.03.07 14:06) [4]
Desdechado © (10.03.07 18:27) [6]
Извините, что сразу не расписал задачу, может быть стало более понятно бы.

Anatoly Podgoretsky © (10.03.07 16:52) [5]
Подходящее название для "монстра".

С уважением.

← →
Desdechado © (2007-03-11 18:03) [8]

Как вариант, конструировать запрос "на лету". Хранить такое в виде ХП смысла не вижу, на все не напасешься. И рекурсия тут тоже нафиг не нужна.
Просто, например, делать что-то такое:
c:="SELECT нужные_поля_из_главной_таблицы" если нужны поля из T1, то с:=c+"поля_из_T1"; ... // + по всем вспомогательным таблицам c:=c+"FROM главная_таблица"; если нужны поля из T1, то c:=c+", T1"; ... // + по всем вспомогательным таблицам если нужны поля из T1, то c:=c+"главная_таблица.ключ = T1.ключ"; ... // + по всем вспомогательным таблицам

← →
databaser (2007-03-11 22:36) [9]

Desdechado © (11.03.07 18:03) [8]
Рекурсия ничем толком не отличается от того append"a строк что вы предлагаете, окромя читабельности. Но это не суть - рекурсию то я использовал для другой структуры запроса, где она была уместна. В вашем варианте ей не место это точно.

Вся проблема была в том, что я возможно изготовил неоптимальный запрос (вложенные) изначально. Вариант с простым WHERE (я его почему то сразу отложил, поэтому долго не понимал о чем вы говорите с Johnmen) и динамическим формированием выглядит, конечно, куда более страшно, но по скорости наверное должен быть шустрее.

Теперь по поводу использования SP. Мне необходимо минимизировать время уходящее на запрос. Если я использую вариант с динамической генерацией - получаю "ужас". Если параметризированный запрос, то надо заготавливать кучу готовых, заранее сгенерированных, запросов и хранить их либо в куче TADOStoredProc, либо в mdb и использовать 1 SP.

1) В первом случае "лишнее" время тратится на закрытие датасета, парсинг SQL запроса.

2) Во втором случае все идеально, окромя нескольких десятков SP...

3) В третьем нету парсинга, но имеет место закрытие датасета, которое жрет прилично судя по результатам профилирования.

Относительно задачи. Конечный пользователь часто выполняет запросы, как с одним критерием (тут проблем нету), так и с несколькими. Запросы могут повторяться и т.д. В общем пользователь в полную силу использует все информационные ресурсы БД.

← →
MsGuns © (2007-03-11 23:50) [10]

>databaser (11.03.07 22:36) [9]

Повторяю еще раз:

Для задачи, котрую Вы описали, не может быть сложного поиска, а если он все-таки "вытанцовывается", то либо учить сиквель до изнеможения, либо база спроектирована из рук вон

← →
Sergey13 © (2007-03-12 08:28) [11]

Теоретически наверное можно написать 1 запрос с фильтрами типа
(:par1 is null or Field1=:par1)
на все вероятные поля поиска. Но практической пользы по сравнению с динамическим созданием запроса я думаю это не принесет. Не думаю (но не утверждаю этого), что у аксеса есть кэш запросов, а следовательно бороться за отсутствие парсинга не имеет смысла.

← →
Jeer © (2007-03-12 09:30) [12]

> Многокритериальный поиск [D7, MS Access]

Почитайте об OLAP (MOLAP vs ROLAP) - возможно полегчает.
(гиперкубы, виртуальные звезды и пр. технологии WareHouse + DataMining)

Могу посоветовать взглянуть на технологию Дедуктора от basegroup
http://basegroup.ru/

← →
databaser (2007-03-12 09:51) [13]

Sergey13 © (12.03.07 08:28) [11]
Да, как раз об этом подумал, когда увидел ваши (и не только) посты в соседней теме. Попробую. По теме кэша запросов и борьбы за отсутствие парсинга - писал тестовое приложение, использовал, как обычно, AQTime для перфоманс профайла. Динамическая генерация (а следовательно и парсинг) - серьезно проигрывает параметризированным запросам.

Jeer © (12.03.07 09:30) [12]
Спасибо! Пошел курить маны. Basegroup помню, пару лет назад сталкивался. Сомнительно в плане применения в моей задаче.

← →
databaser (2007-03-12 09:54) [14]

> Рекурсия ничем толком не отличается от того append"a строк
> что вы предлагаете, окромя читабельности.
Еще как отличается. Подзапросы обычно в разы неэффективнее, чем соединения таблиц по ключам.

> (:par1 is null or Field1=:par1)
Не боишься картезиан схватить?

> Динамическая генерация (а следовательно и парсинг) - серьезно
> проигрывает параметризированным запросам.
Это перпендикулярные понятия. парсинг есть в любом случает. А параметризированные запросы могут создаваться как динамически, так и храниться статически.

← →
databaser (2007-03-12 21:12) [17]

Desdechado © (12.03.07 11:35) [15]
Кто такой картезиан? Яндекс выдал море инфы, но она меня смущает )

(:par1 is null or Field1=:par1) - мне нравится этот вариант. Таким образом можно сделать параметризированный запрос без динамической генерации. Насколько будет быстрее, обязательно сообщу потом.

>Кто такой картезиан?
декарово произведение, full join.

декарТово

Многокритериальный поиск Найти похожие ветки