Шмрокое использование вложенного запроса в IN

← →
kaif © (2004-04-29 16:30) [0]

Вот пытаюсь сделать как бы "виртуальные папки", в которые продвинутый юзер мог бы вписать запрос к справочной системе в моей программе. Например, есму хочется "все принтеры" HP собрать в одну папку "для удобства". чтобы он мог записать что-то вроде SELECT ID FROM ... WHERE ... = "HP".
Однако сама система управления справочниками достаточно сложная. Так вот есть идея сделать так:
Система свой автоматический хитрый и навороченный запрос дополняет в условии WHERE простым подзапросом пользователя. Так как все справочние элемены образуют общее пространство ID, получается так:

SELECT
....
FROM
....
....
....
WHERE
....
....
AND ID IN (<запрос пользователя, возвращающий значения ID>)

Можно ли пойти по этому пути? Пока я получил замедление запросов всего процентов на 10 по сравнению с "оптимальным запросом" (без подзапроса). Но это пока на 10тыс. записях в справочной системе.

← →
kaif © (2004-04-29 17:06) [1]

Приведу пример

SELECT GOODS.ID GOODS_ID, GOODS.ARTICLE_OLD, GOODS.ARTICLE, GOODS.MANUFACTURER, O1.SHORT_NAME MANUFACTURER_LK, GOODS.PRICE1, GOODS.PRICE2, GOODS.PRICE3, GOODS.MARK, BED_CLOTHES.BED_DECOR, O2.SHORT_NAME BED_DECOR_LK, PILLOW_CASE.PILLOW_CASE_KIND, O3.SHORT_NAME PILLOW_CASE_KIND_LK FROM GOODS, OBJECT_NAMES O1, BED_CLOTHES, OBJECT_NAMES O2, PILLOW_CASE, OBJECT_NAMES O3 WHERE GOODS.MANUFACTURER=O1.OBJECT_ID AND GOODS.ID=BED_CLOTHES.ID AND BED_CLOTHES.BED_DECOR=O2.OBJECT_ID AND GOODS.ID=PILLOW_CASE.ID AND PILLOW_CASE.PILLOW_CASE_KIND=O3.OBJECT_ID AND GOODS.ID IN (SELECT OBJECT_ID FROM OBJECT_NAMES WHERE SHORT_NAME LIKE "%65x%")AND GOODS.ID IN (SELECT OBJECT_ID FROM OBJECT_NAMES WHERE SHORT_NAME LIKE "%прош%") ORDER BY GOODS.ID

Выделенный код - 2 подзапроса пользователя. Он как бы создал папку, в которой хочет видеть все наволочки с размером "65x" и добавил еще одну "дочернюю папку", в которой останутся все такие наволочки, но к тому же "прошитые". Фильтацию пользователь сделал на основе вхождения в наименование SHORT_NAME. Я как бы вставил из каждой папки подзапрос в основной запрос, сужая тем самым результирующее множество записей.

Время запроса с одним дополнительным условием 0.070 сек, а с двумя - уже 0.35 сек на процессоре 850 МГц.

← →
Sandman25+1 (2004-04-29 17:19) [2]

Почему нет? Особенно если предусмотреть "библиотеку виртуальных папок" для наиболее полезных папок. И возможно обработку специальных идентификаторов типа CurrentUser, BeginOfCurrentYear, BeginOfCurrentMonth, CurrentOffice и т.д., причем обработка и конвертация в SQL может вестись в Delphi, чтобы не заставлять пользователя учить тяжелый SQL.

← →
kaif © (2004-04-29 18:40) [3]

А кто реализовывал подобные вещи? Меня интересует Ваш опыт. Юзеры такие примочки вообще используют? Или им милее папки-коллекции, в которые можно что-то просто складывать? То есть будут ли юзеры вообще рады виртуальным папакам-фильтрам? Вот в Outlook2003 такие папки вроде есть. Но я не знаю пока никого, кто бы юзал Outlook2003. Есть ли смысл вообще заморачиваться?

← →
Petr V. Abramov © (2004-04-29 19:11) [4]

IMHO, тормоза из-за LIKE "%65x%"

← →
Sandman25+1 (2004-04-30 13:45) [5]

[3] kaif © (29.04.04 18:40)

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

← →
kaif © (2004-04-30 23:40) [6]

Странно, что SQL считается чем-то сложным.
По-моему IBM в свое время изобрела этот язык именно для юзеров...
Как же они свой бизнес делают, если SQL для них сложен?

← →
Sergey Masloff (2004-05-01 00:41) [7]

kaif © (30.04.04 23:40) [6]
>Как же они свой бизнес делают, если SQL для них сложен?
очень хорошо обычно делают. И всякой чушью себе головы не забивают ( и правильно делают). Потому что SQL прост только на простых примерах. И мне в страшном сне не приснится пускать юзера с SQL-ем в руках к моей базе. Ну серьезно... Нельзя так.

← →
Narayan © (2004-05-01 11:58) [8]

юзер с SQL-ем в руках не так уж страшен, его ж можно в правах ограничить

2 Sergey Masloff (01.05.04 00:41) [7]
Ну а почему? Если мы используем только метод Open компонента типа TIBDataSet, то никакие опасные команды (insert, delete, update, grant, create, alter, drop) попросту не сработают.
Юзер может использовать простые запросы. А сложные при нормальной организации данных и не нужны. К тому же если речь идет о фильтрации справочников, а не о получении финансовых отчетов, то, ИМХО, ничего здесь опасного нет. Максимум, чем мы рискуем - юзер будет задавать вопросы, "почему я написал такой запрос, а там такие элементы не видны, которые я бы хотел, чтобы были видны". Получив ответ на такой вопрос, юзер уже обучается SQL. Что, собственно и требуется. А если вопрос ламерский - можно послать к "руководству по SQL для простых смертных", которое опубликовать в документации.

← →
Sergey Masloff (2004-05-01 21:56) [10]

kaif © (01.05.04 14:40) [9]
> Ну а почему? Если мы используем только метод Open компонента >типа TIBDataSet,
Я не в этом смысле. 2 примера. Таблица a - 150 тыс. записей. Таблица b - 30 тас записей

первый: запрос вида
select a.id from a where a.shortname like "%x%"

второй: запрос вида
select a.id, b.id from a, b

Обе эти команды вроде бы и не опасны, но на IB они могут уложить сервер на полчасика работы со 100% загрузкой процессора. К чему это приведет в многопользовательской среде когда экономист запустил такое а в кассу стоит десяток людей которые очень торопятся объяснять думаю не надо. А виноват будешь ты - твоя система такое позволяет!

>А сложные при нормальной организации данных и не нужны
Ну, с этим можно спорить но это уже Holy War а я в них стараюсь не принимать участия. (получается не всегда)

Кстати, как это ни странно, среднему человеку проще написать на чем-то типа 1сMudLang, чем на SQL, хоть и будет в 10 раз длинне, кривее и тормознее.
По моим наблюдениям над людьми, считающими, что программирование - это просто и лезущими что-то исправить :)

2 Sergey Masloff (01.05.04 21:56) [10]
Убедил. Я совершенно забыл про декартово произведение. Видимо, действительно юзеру непосредственно в SQL делать нечего. :(
Или нужен хитрый парсер, анализирующий такие промахи. Овчинка выделки явно не стоит... Спасибо.

Шмрокое использование вложенного запроса в IN Найти похожие ветки