Может быть вопрос не совсем по теме форума, но поскольку система будет писаться на ASA 9.0.1 и соответственно будут работать особенности оптимизатора запросов именно этого сервера, пишу сюда. :)

Описание условий:

Классическая стурктура для хранения информации по учету заключения договоров - справочники фирм, справочники физ. лиц, информация о платежах, прочие реквизиты договоров. Основная таблица - договор, который как сам содержит ссылки на участников договора, так и на него ссылаются другие таблицы, например платежи.

Задача:

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

Поскольку информация хранится в разных таблицах, первое, что приходит в голову - создать view, в котором выбираются поля для отображения, а условия поиска подключать коррелированными подзапросами с условием

and exists (select 1 from table1 where table_id = view_id)

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

Решал ли кто-нибудь подобные задачи и как выходил из положения?

ASCRUSСхема прекрасно работает, не смотря на то, что в запросе перечислены все таблицы и из них может быть в фильтре потребуется только одна. Оптимизатор ASA выкидывает из построения плана запроса ненужные таблицы и соотвествующе скорость работы будет нормальной.

Примерно такой же вариант я когда-то делал для ASE, но там оптимизатор работает немного иначе и не всегда использовались те индексы, на которые я рассчитывал, приходилось указывать их явно и универсальность постепенно терялась. Здесь вроде бы ситуация с оптимизацией получше.

Возник такой вопрос: насколько я знаю, для ASA по умолчанию INNER JOIN = KEY JOIN, т.е. это получается строгий поиск, когда выполняются все условия и данные есть во всех связываемых таблицах. Не совсем ясно, что произойдет, если в одной из объединяемых таблиц нет данных по логической связке и в данном наборе условий поиска ее поля не используются?

Например, если в схеме



еще нет платежей, но нужно найти все договора с определенным участником. Выкинет ли оптимизатор эту таблицу и вернет какой-то набор данных или все-таки ничего не вернет?

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

2 ASCRUS

Спасибо, попробую такой поиск на одной старых систем.