Inerbase - хранимые процедуры

← →
novichek (2011-03-03 17:33) [0]

Подскажите пожалуйста, немножко не понимаю разницу между хранимой в базе процедурой и sql запросом.

Ведь sql запрос обрабатывается на сервере и если я, например, в sql запросе осуществляю выборку по определенным данным или изменение определенного диапазона данных то все это и обрабатывается на сервере?

при select c where клиенту же прийдут только отфильтрованные данные?
или прийдут все, а приложение будет осуществлять фильтрацию?

простите если туплю )

← →
clickmaker © (2011-03-03 17:38) [1]

> разницу между хранимой в базе процедурой и sql запросом

букварь какой-нибудь по БД/SQL почитай.
Если кратко. Хранимка - запрос, хранящийся на сервере. Поскольку он уже составлен и сохранен, сервер может его оптимизировать, составить план выполнения и закэшировать для более быстрой обработки (скомпилировать). К тому же, к хранимкам легко применять правила безопасности для ролей/пользователей, так как это объект БД, как таблица, например

← →
han_malign (2011-03-03 17:46) [2]

> Хранимка - запрос, хранящийся на сервере.

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

← →
Sergey13 © (2011-03-03 17:47) [3]

> [1] clickmaker © (03.03.11 17:38)
> Хранимка - запрос, хранящийся на сервере.

Это все таки процедура, написанная на языке сервера, сохраненная и выполняемая на сервере же.

> [0] novichek (03.03.11 17:33)

Запрос - это законченное предложение. Процедура - это целый рассказ. 8-)

> при select c where клиенту же прийдут только отфильтрованные данные?
Да. Но после поступления данных на клиенте доступна своя, локальная фильтрация. Это разные вещи.

← →
novichek (2011-03-03 17:57) [4]

спасибо большое за ответы!

допустим в базе 100 тысяч записей..

какова примерно разница между запросом на select, допустим результат около 1000 записей будут удовлетворять условию, при обычном SQL и через хранимую процедуру ?

и я немножко не понимаю
"сервер может его оптимизировать, составить план выполнения и закэшировать для более быстрой обработки"

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

просто страшно пока что подходить к хранимым процедурам, отчего мысли в голове, может можно и без них и будет все не существенно тормознутее (:

← →
clickmaker © (2011-03-03 18:02) [5]

> ведь параметры в хранимую процедуру я могу передать разные,
> серверу х.з. что и кешировать

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

← →
novichek (2011-03-03 18:32) [6]

спасибо большое!
пошел искать умные книги )

пожалуйста посоветуйте что использовать в качестве сервера: InterBase 2009 или последний FireBird ?

что более стабильно работает и меньше проблем с установкой и обслуживанием базы?

← →
_Юрий (2011-03-03 19:02) [7]

> clickmaker © (03.03.11 18:02) [5]

насколько я знаю, план запроса сервер может составить и при внешнем запросе.

> novichek (03.03.11 18:32) [6]

> пожалуйста посоветуйте что использовать в качестве сервера:
> InterBase 2009 или последний FireBird ?

FireBird, ибо бесплатен

← →
Игорь Шевченко © (2011-03-03 19:34) [8]

> насколько я знаю, план запроса сервер может составить и
> при внешнем запросе.

Более того, он без плана даже работать не будет :)

← →
novichek (2011-03-03 19:46) [9]

на InterBase есть лицензия.. но если FireBird лучше тогда начну с него..

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

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

а для простого select с каким-то условием отбора можно обойтись и внешним запросом..

← →
Игорь Шевченко © (2011-03-03 20:11) [10]

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

мало прочитал, читай дальше

← →
Loginov Dmitry © (2011-03-03 21:50) [11]

> что более стабильно работает и меньше проблем с установкой
> и обслуживанием базы?

FireBird. Нет проблем с установкой. Нет проблем с обслуживанием базы данных. Работает стабильно, нареканий нет. Только использовать нужно последние релизы (можно и кандидаты в релизы, но иногда это рискованно :).

> > пожалуйста посоветуйте что использовать в качестве сервера:
>
> > InterBase 2009 или последний FireBird ?
>
>
> FireBird, ибо бесплатен

И пишут его наши ребята, и изучен он у нас в России намного лучше ;)

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

Да и для сложного запроса можно не пользоваться хранимой процедурой. Можно использовать EXECUTE BLOCK (появился в FB2.0), в котором заключен код процедурного SQL.
Но следует понимать, что в некоторых случаях удобнее пользоваться именно хранимыми процедурами / представлениями, а в других случаях - сложным SELECT или EXECUTE BLOCK.
Если твоей задачей становится администрирование некоторой объемной базы данных, к которой подключается множество клиентов, то гораздо удобнее использовать хранимые процедуры / представления.
Еже ли ты являешся разработчиком какого-то офисного коробочного ПО, причем регулярно обновляемого, то удобнее заключать необходимые запросы именно в код ПО (это проще, чем возиться в DDL).

>
> хранимые процедуры вероятно оправдывают себя при многоуровневых
> запросах.

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

← →
clickmaker © (2011-03-03 22:41) [12]

> [7] _Юрий (03.03.11 19:02)
> насколько я знаю, план запроса сервер может составить и
> при внешнем запросе

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

← →
Кщд (2011-03-04 09:26) [13]

>novichek (03.03.11 17:33)
http://edn.embarcadero.com/article/27197
до просветления

> [9] novichek (03.03.11 19:46)

Процедура нужна тогда, когда просто запросом сделать нужное не получается. ИМХО.

> просто запросом сделать нужное не получается

да при желании все можно сделать запросом. Ну, кроме рекурсии разве что. Только надо ли?

> [15] clickmaker © (04.03.11 16:03)

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

> Ну в процедуре ведь не только запросы могут быть

ну, под запросами я имею в виду DML вообще

Inerbase - хранимые процедуры Найти похожие ветки