Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Шмрокое использование вложенного запроса в IN [IB6.x, Firebird, Yaffil]

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

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

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

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

Petr V. Abramov (2004-05-01 22:12:00) [2]
Кстати, как это ни странно, среднему человеку проще написать на чем-то типа 1сMudLang, чем на SQL, хоть и будет в 10 раз длинне, кривее и тормознее.
По моим наблюдениям над людьми, считающими, что программирование - это просто и лезущими что-то исправить :)

Sergey Masloff (2004-05-01 21:56:00) [3]
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 а я в них стараюсь не принимать участия. (получается не всегда)

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

Narayan (2004-05-01 11:58:00) [5]
юзер с SQL-ем в руках не так уж страшен, его ж можно в правах ограничить

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

kaif (2004-04-30 23:40:00) [7]
Странно, что SQL считается чем-то сложным.
По-моему IBM в свое время изобрела этот язык именно для юзеров...
Как же они свой бизнес делают, если SQL для них сложен?

Sandman25+1 (2004-04-30 13:45:00) [8]
[3] kaif © (29.04.04 18:40)

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

Petr V. Abramov (2004-04-29 19:11:00) [9]
IMHO, тормоза из-за LIKE '%65x%'

kaif (2004-04-29 18:40:00) [10]
А кто реализовывал подобные вещи? Меня интересует Ваш опыт. Юзеры такие примочки вообще используют? Или им милее папки-коллекции, в которые можно что-то просто складывать? То есть будут ли юзеры вообще рады виртуальным папакам-фильтрам? Вот в Outlook2003 такие папки вроде есть. Но я не знаю пока никого, кто бы юзал Outlook2003. Есть ли смысл вообще заморачиваться?

Sandman25+1 (2004-04-29 17:19:00) [11]
Почему нет? Особенно если предусмотреть "библиотеку виртуальных папок" для наиболее полезных папок. И возможно обработку специальных идентификаторов типа CurrentUser, BeginOfCurrentYear, BeginOfCurrentMonth, CurrentOffice и т.д., причем обработка и конвертация в SQL может вестись в Delphi, чтобы не заставлять пользователя учить тяжелый SQL.

kaif (2004-04-29 17:06:00) [12]
Приведу пример

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 МГц.

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »