реализация запросов

← →
stud © (2004-04-21 14:11) [0]

интересует мнение по вопросу каким образом лучше реализовывать запросы: с помощью хп на сервере или динамически формировать на клиенте? в чем преимущества и недостатки каждой реализации?
в литературе встречал рекомндацию, что не стоит все запросы реализовывать с помощью хп..

← →
Reindeer Moss Eater © (2004-04-21 14:12) [1]

А что такое "реализовывать запросы"?

← →
Курдль © (2004-04-21 14:17) [2]

> не стоит все запросы реализовывать с помощью хп..

Вот именно! Я уже говорил, что чаще всего вообще конструирование замысловатых ХП - это роспись в собственной беспомощности составить грамотный запрос.

← →
stud © (2004-04-21 14:17) [3]

возможно непонятно выразился.
т.е. все необходимые запросы (select) выполнятся с помощью хранимых процедур.

← →
Курдль © (2004-04-21 14:20) [4]

Многие СУБД вообще не заточены возвращать набор данных из ХП.
Так что Ваша парадигма - тупиковая.

← →
stud © (2004-04-21 14:20) [5]

> ХП - это роспись в собственной беспомощности составить грамотный
> запрос.

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

← →
Reindeer Moss Eater © (2004-04-21 14:20) [6]

что не стоит все запросы реализовывать с помощью хп..

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

← →
stud © (2004-04-21 14:56) [7]

ну пока разговор о конкретном сервере FB 1,5

← →
Курдль © (2004-04-21 15:02) [8]

> т.е. все необходимые запросы (select) выполнятся с помощью
> хранимых процедур.

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

А сами-то как думаете? В одном случае Вы получите НД непосредственно от запроса, а в другом - от запроса, инициированного процедурой, которую Вы вызвали.
И еще раз напоминаю, если IB умеет возвращать набор данных из процедуры - то она в явном меньшинстве. Другие СУБД Вам этого не позволят.

← →
kaif © (2004-04-21 15:08) [9]

ИМХО, в ХП следует реализовывать то, что при помощи одного единственного SQL-запроса не сделаешь.

← →
Fay © (2004-04-21 15:13) [10]

MSSQL умеет.
Oracle(не проверял) - тоже.

← →
Fay © (2004-04-21 15:13) [11]

Sybase ASE - умеет

← →
Nikolay M. © (2004-04-21 15:16) [12]

Ширее надо смотреть, граждане!
Допустим, написал программист 100-этажный запрос, в котором какая-нибудь таблица джойнится сама на себе 50 раз (про вопрос, на фига это делать, про то, что скорее всего половина соединений не будет использовать индексы, что каждый раз будет подниматься план выполнения этого запроса, я молчу). Отдали программу внедренцам, те у заказчика ставят программу и, опа-на!, а запрос-то не совсем коректный! Что будет проще - подправить на месте текст ХП (которую можно постараться написать так, что и индексы будут грамотно использоваться, и логика будет прозрачная, и план выполнения уже будет готов) или пинать головной офис, чтобы программисты латали заплатку в коде программы?

← →
stud © (2004-04-21 15:20) [13]

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

← →
Курдль © (2004-04-21 15:22) [14]

> Fay © (21.04.04 15:13) [10]
> MSSQL умеет.
> Oracle(не проверял) - тоже.
> Sybase ASE - умеет

Приведите, плз, по одному простенькому примеру для каждой.

← →
Nikolay M. © (2004-04-21 15:26) [15]

> Курдль © (21.04.04 15:22) [14]
> Приведите, плз, по одному простенькому примеру для каждой.

MS SQL & Sybase:

CREATE PROC Test
AS
SELECT getdate()

← →
Fay © (2004-04-21 15:29) [16]

хп и анонимные блоки в ASE и MSSQL могут вернуть челое нетрицательное количество датасетов.

← →
Nikolay M. © (2004-04-21 15:30) [17]

> Fay © (21.04.04 15:29) [16]
> анонимные блоки

Это что, если не секрет?

← →
Курдль © (2004-04-21 15:31) [18]

> Nikolay M. © (21.04.04 15:26) [15]

То, что указанные Вами СУБД умеют работать с ХП и использовать в них запросы - это понятно. Дайте пример ХП, возвращающей НАБОР ДАННЫХ

← →
Fay © (2004-04-21 15:33) [19]

Nikolay M. © (21.04.04 15:30) [17]
select getdate()
select getdate()
select getdate()
select getdate()
select getdate()

2Курдль © (21.04.04 15:31) [18]
create procedure bububu
as
select * from table1

← →
stud © (2004-04-21 15:35) [20]

> Курдль © (21.04.04 15:22) [14]

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

← →
Reindeer Moss Eater © (2004-04-21 15:37) [21]

Например потеряешь бесплатную рюшечку в виде live queries

← →
Sergey_Masloff (2004-04-21 15:39) [22]

Nikolay M. © (21.04.04 15:16) [12]
угу, один из примеров когда ХП нужны.

Еще иногда очень нежелательно давать клиенту возможность выполнять произвольные запросы (а когда запрос формируется на клиенте - оно так и есть). С помощью XП закрыть это - милое дело. А внутри ХП может быть и один запрос - это не так важно

← →
Курдль © (2004-04-21 15:43) [23]

> Nikolay M. © (21.04.04 15:26) [15]
> MS SQL & Sybase:

Ну дык когда дело до оракла дойдет? :)

Ладно, сдаюсь! Нет универсальной догмы это лучше!
Для каждого случая - свой подход.

← →
stud © (2004-04-21 15:44) [24]

> в виде live queries

это как?

← →
Fay © (2004-04-21 15:45) [25]

2Курдль © (21.04.04 15:43) [23]
>> Ну дык когда дело до оракла дойдет? :)

Я чё-то не понял - кто тут ораклоид?

← →
Sergey_Masloff (2004-04-21 15:56) [26]

Ну а что ORACLE? В нем как раз очень просто за счет рефкурсоров
FUNCTION ReturnCustomCursor(pInput in number) return TRefCursor IS BEGIN OPEN cMyCursor FOR SELECT * FROM MyFavoriteTable WHERE FILTER = pInput ORDER BY MYSORTFIELD; return cMyCursor ; END;

← →
Nikolay M. © (2004-04-21 16:03) [27]

> Ладно, сдаюсь! Нет универсальной догмы это лучше!

Yesss-yesss-yessss :))))

> Sergey_Masloff (21.04.04 15:39) [22]

Да, если разграничение прав построено на основе оболочки из процедур вокруг собственно таблиц, то придется даже простейшие селекты оформлять в виде ХП.
Кстати, это камень в огород "нет универсальной догмы" :)

← →
Курдль © (2004-04-21 16:09) [28]

А кто такой TRefCursor?

2Nikolay M. © (21.04.04 16:03) [27]
>> Кстати, это камень в огород "нет универсальной догмы" :)
Смотрел в огороде "нет универсальной догмы". Такого камня не видел.

жаль, что нам так и не удалось услышать начальника транспортного цеха)))

← →
Sergey_Masloff (2004-04-21 16:21) [31]

>А кто такой TRefCursor?
TYPE TRefCursor IS REF CURSOR

можно еще так
TYPE TMyTableCursor IS REF CURSOR RETURN MYTABLE%ROWTYPE;

жаль, что нам так и не удалось услышать начальника транспортного цеха)))

← →
Sergey_Masloff (2004-04-21 16:26) [33]

Nikolay M. © (21.04.04 16:03) [27]
>Да, если разграничение прав построено на основе оболочки из >процедур вокруг собственно таблиц, то придется даже простейшие >селекты оформлять в виде ХП.
Можно написать несколько универсальных ХП которые принимают строку параметров вида param1=val1;param2=val2 и так далее и на основе строит конкретный текст запроса НА СЕРВЕРЕ и НА СЕРВЕРЕ его же выполняет. То есть пользователь имеет очень большое количество запросов которые реализуют всего несколько ХП. И это не теория - я активно применяю реализацию такого подхода (как на ORACLE так и IB). Но конечно для построения комплексных запросов на сервере (при необходимости с хинтами и так далее) нужно руку набить. Хотя ничего невозможного нет.

> Sergey_Masloff (21.04.04 16:26) [33]

Обоснованность такого решения неочевидна (по крайней мере для меня).
1) Запрос в этом случае строится ДИНАМИЧЕСКИ, т.е. теряется прелесть использования построенного плана выполнения запроса.
2) Если с помощью нескольких ХП юзеры могут получить практически любые НД из десятка таблиц, почему бы просто не дать им права на чтение напрямую из таблиц?

← →
Sergey_Masloff (2004-04-21 17:37) [35]

Nikolay M. © (21.04.04 17:08) [34]
Нет не любые. Используется активно в отборах. Там скорость приносится в жертву универсальности и гибкости. Так что замечание 1) справедливо но не критично.

По 2). Не любые НД а НД которые я им даю. Они могут сформировать только сколь угодно сложное ограничение на НД.
Возьмем пример отбора счетов. Наверное в результате отбора юзер желает увидеть только небольшой набор атрибутов - плательщик получатель номер сумма недостающее добавить. Но условия отбора могут варьироваться очень сильно и требовать массы джойнов. Так вот пользователь всегда передает сконкатенированый в строку список параметров а я проходя его в цикле строю запрос произвольной сложности. Ну и возвращаю ему его НД. На самом деле есть там немало хитростей которые объяснять а) долго б) нельзя но поверь с таким подходом можно сделать ОЧЕНЬ гибкую систему (ну например как тебе хранение истории кто и что и когда отбирал. Знаешь, иногда ОЧЕНЬ полезно).

Аргументы понятны, на словах выглядит красиво.
Но воспринимается пока скептически. Для реализации такой схемы надо строить оболочку вокруг исходных таблиц (где какие данные лежат, как их доставать), которая будет сильно зависеть от структуры БД -> трудность поддержки.
Также мне лично не кажется данный подход более удобным по сравнению с более общепринятым "один отчет - одна ХП", где можно построить оптимальные запросы для каждого отдельно взятого отчета + большая гибкость при изменениях в отчетах и структуре БД.
А уж реализовать историю просмотров можно и массой других способов.

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

← →
Sergey_Masloff (2004-04-21 18:13) [38]

Nikolay M. © (21.04.04 18:05) [36]
Один отчет-одна ХП не напасешься ХП. Естественно такие отчеты строятся не по оперативной базе. А это - оперативные отборы. Поддерживать как раз не очень сложно, а изменения структуры БД... Не знаю. У нас системе уже с десяток лет никаких изменений структуры БД не было (ну почти не было). Просто хорошо спроектировали в самом начале (я не принимал участия). Система полностью автоматизирует крупную компанию с очень непростым бизнесом. И ничего, как-то обходимся старыми структурами ;-)

> а почему один отчет- одна хп?

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

> Один отчет-одна ХП не напасешься ХП.

Свой и чужой опыт подсказывает, что жить, в принципе, можно :)

> И ничего, как-то обходимся старыми структурами ;-)

Ясно. На самом деле, то, что это работает - это самый главный аргумент, так что утихаю :)

← →
Sergey Masloff (2004-04-21 22:23) [40]

Nikolay M. © (21.04.04 18:18) [39]
>Свой и чужой опыт подсказывает, что жить, в принципе, можно :)
Да мой тоже подсказывает что можно ;-) Я ж не панацею а один из вариантов привел ;-)

Навскидку что еще реализовано:
1) Результат запроса "хранится". Срок его жизни задается (по умолчанию до полуночи)
2) Результат запроса можно послать произвольному числу пользователей. То есть я запустил запрос который работал 10 минут потом шлю тебе сообщение - смотри что тут за фигня и посылаю тебе запрос без доп. затрат (в том числе затрат трафика - реально пересылается несколько байт)
3) Можно посмотреть историю своих запросов и повторно выполнить какие-то практически без оверхеда

Но повторяю - это лишь один из вариантов и естественно на все случаи жизни его не распространишь ;-)

реализация запросов Найти похожие ветки