Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4   вперед  Ctrl      все
 Re: Динамический SQL. Можно ли обойтись без него.  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 64001
Блог
Хрюхрюшкин.
Грузить — из СУБД в клиента, я имел в виду.

Я тоже.
3 июл 07, 20:56    [4346697]     Ответить | Цитировать Сообщить модератору
 Re: Динамический SQL. Можно ли обойтись без него.  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18373
Хрюхрюшкин.
Грузить — из СУБД в клиента, я имел в виду. В realtime'е, конечно. Либо не только в клиента, но и куда-то еще.

Для "порционной" выборки данных из БД применяются обычные пакетные операции с курсором.
Они доступны как для REF, так и для обычных курсоров как в OCI, так и в PL/SQL - не уверен на счет java, но, думается, там тоже все должно быть.
3 июл 07, 20:59    [4346711]     Ответить | Цитировать Сообщить модератору
 Re: Динамический SQL. Можно ли обойтись без него.  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18373
softwarer
Хрюхрюшкин.
Грузить — из СУБД в клиента, я имел в виду.

Я тоже.

Не претендуя на истину в последней инстанции, приведу привычные моему скромному уху шаблонные буквосочетания:
"Загрузка данных" - в сторону БД
"Выгрузка данных", "Выборка данных" - в сторону клиента
3 июл 07, 21:01    [4346716]     Ответить | Цитировать Сообщить модератору
 Re: Динамический SQL. Можно ли обойтись без него.  [new]
Relic Hunter
Member

Откуда: AB
Сообщений: 7435
автор
Динамический SQL. Можно ли обойтись без него.
Можно. Для таких задач используют динамический "where clause". Общепринятая практика. Сам запрос формируется статически, а к нему пристегивается любой "where clause", передаваемый с клиента. Ну и про "pagination" не забываем :)
4 июл 07, 07:25    [4347188]     Ответить | Цитировать Сообщить модератору
 Re: Динамический SQL. Можно ли обойтись без него.  [new]
аналитик, блин
Guest
Relic Hunter
автор
Динамический SQL. Можно ли обойтись без него.
Можно. Для таких задач используют динамический "where clause". Общепринятая практика. Сам запрос формируется статически, а к нему пристегивается любой "where clause", передаваемый с клиента. Ну и про "pagination" не забываем :)
1 кг повидла + 1 кг дерьма = 2 кг дерьма
Следствие: статический запрос + динамический where = динамический запрос.
4 июл 07, 08:46    [4347316]     Ответить | Цитировать Сообщить модератору
 Re: Динамический SQL. Можно ли обойтись без него.  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 64001
Блог
аналитик, блин
Следствие: статический запрос + динамический where = динамический запрос.

Не только. Еще и: "передача where с клиента" + ХП = "SQL с клиента" + "дурацкий геморрой ради удовлетворения тупых формальных критериев"
4 июл 07, 09:18    [4347406]     Ответить | Цитировать Сообщить модератору
 Re: Динамический SQL. Можно ли обойтись без него.  [new]
аналитик, блин
Guest
softwarer
аналитик, блин
Следствие: статический запрос + динамический where = динамический запрос.

Не только. Еще и: "передача where с клиента" + ХП = "SQL с клиента" + "дурацкий геморрой ради удовлетворения тупых формальных критериев"
Я вижу в этом один положительный момент: наличие стандарта (тупых формальных критериев), даже не совсем хорошего, хуже его отсутствия.
4 июл 07, 09:23    [4347423]     Ответить | Цитировать Сообщить модератору
 Re: Динамический SQL. Можно ли обойтись без него.  [new]
Elic
Member

Откуда:
Сообщений: 29990
mcureenab
DBMS_SQL, а на выходе ref cursor.
Придётся думать ещё
STFF поизвращаться с динамическим динамическим SQL
4 июл 07, 09:35    [4347455]     Ответить | Цитировать Сообщить модератору
 Re: Динамический SQL. Можно ли обойтись без него.  [new]
аналитик, блин
Guest
аналитик, блин
Я вижу в этом один положительный момент: наличие стандарта (тупых формальных критериев), даже не совсем хорошего, хуже его отсутствия.
правочка: наличие стандарта конечно, лучше, чем его отсутствие вообще
4 июл 07, 09:46    [4347501]     Ответить | Цитировать Сообщить модератору
 Re: Динамический SQL. Можно ли обойтись без него.  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 64001
Блог
аналитик, блин
Я вижу в этом один положительный момент: наличие стандарта (тупых формальных критериев), даже не совсем хорошего, хуже его отсутствия.

Наличие плохого стандарта, безусловно, хуже его отсутствия. В таких случаях я обычно говорю нечто вроде "а у нас по стандарту везде нужно употреблять цикл while, а циклы for и do запрещены к использованию".
4 июл 07, 09:46    [4347506]     Ответить | Цитировать Сообщить модератору
 Re: Динамический SQL. Можно ли обойтись без него.  [new]
Еще один наивный
Guest
Простите, коллеги, так работы поднавалило, что и почитать форум некогда. :(. Спасибо за ваши ответы.
Итак, попробуем составить общий список недостатков переноса всех запросов в ХП:

1. Перенос формирования запроса в ХП неизбежно приводит к использованию динамического SQL. Это в свою очередь приводит к проблеме применения bind-переменных, одним из решения которой может являться применение контекстов. В результате, получается сложный для написания, восприятия и отладки код. Перестает работать автоматическая проверка кода на корректность на этапе компиляции, перестают работать средства выделения синтаксиса в инструментах...
2. Довольно часто могут встречаться сложные наборы условий формируемые пользователями на клиенте. Для передачи наборов этих условий необходим какой-то, желательно единообразный, механизм/'язык’, что само по себе является непростой и явно лишней проблемой - фактически замена SQL. Язык PL/SQL не очень хорошо приспособлен для разбора таких наборов условий на сервере.
3. Многие изменения требований повлекут за собой изменения, как на стороне клиента, так и на стороне сервера. Например, добавить столбец в грид. Вероятность возникновения именно таких требований (вовлекающих и клиент и сервер) представляется более высокой, нежели вероятность появления задач требующих изменения только на сервере. Хотя, нельзя не признать, что могут появляться случаи изменения только логики запроса и тогда их можно решить только на уровне сервера.
4. Усложняется процесс внесения изменений «на лету» - он потребует отключения пользователей от сервера.
5. Упрощение администрирования (дать права только на один пакет и все) выглядит сомнительным. Вот об этом, конечно, хотелось бы поподробнее.
6. Возникают дополнительные вопросы безопасности – недопущения передачи в ХП каких-либо условий запроса способных нарушить авторизационную модель


Все верно? Можем еще что-то добавить?
4 июл 07, 16:53    [4351145]     Ответить | Цитировать Сообщить модератору
 Re: Динамический SQL. Можно ли обойтись без него.  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 64001
Блог
Еще один наивный
1. Перенос формирования запроса в ХП неизбежно приводит к использованию динамического SQL.

Почти неизбежно. Есть редкие случаи, когда это не так. Сходу вспомню два варианта:

1. Почтовый робот, который сканировал очередь на отправку, слал, получал, клал в базу.
2. Движок метаинформации, засасывал все в память и там крутил, дальше шли только модификации.

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

Еще один наивный
Перестает работать автоматическая проверка кода на корректность на этапе компиляции, перестают работать средства выделения синтаксиса в инструментах...

Также перестают работать клиентские инструменты - либо их специфические фичи, те же макросы, либо просто функционал, не учитывающий возврат ref cursor-а (скажем, становится проблемой настроить DBGrid по полям, возвращаемым запросом).

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

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

Еще один наивный
5. Упрощение администрирования (дать права только на один пакет и все) выглядит сомнительным. Вот об этом, конечно, хотелось бы поподробнее.

Как правило, "один грант" - дырка в безопасности. Чаще всего требуется, чтобы некий пользователь мог видеть данные, но не мог бы их менять; таким образом, если объединять в одном пакете процедуры выборки и модификации, уже потребуется городить сомнительные собственные велосипеды.

Далее, большинство запросов выводят данные из нескольких таблиц. Это делает практически невозможным контроль над тем, чтобы пользователь не увидел "неположенных" данных; каждый раз, дорабатывая запрос под задачу пользователя А, разработчик должен проверять, а не грантован ли этот пакет пользователю Б, который не должен видеть добавляемых данных. В такой ситуации можно гарантировать: дырки будут.

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

Ну и на всякий случай упомяну - конечно, можно делать все пакеты подряд в AUTHID CURRENT_USER, и таким образом вроде как обойти эти проблемы, но... не стоит так делать, имхо.
4 июл 07, 17:46    [4351584]     Ответить | Цитировать Сообщить модератору
 Re: Динамический SQL. Можно ли обойтись без него.  [new]
псевдоаналитик, блин
Guest
Еще один наивный
1. Перенос формирования запроса в ХП неизбежно приводит к использованию динамического SQL
Любой запрос вне пакета/процедуры - из делфы, например, - может считать себя динамическим.
/* Поправьте меня, люди! */
4 июл 07, 17:54    [4351637]     Ответить | Цитировать Сообщить модератору
 Re: Динамический SQL. Можно ли обойтись без него.  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 64001
Блог
Это больше вопрос терминологии, чем смысла, имхо. Думаю, было бы немного лучше сказать "к необходимости использования динамического SQL на сервере".
4 июл 07, 18:17    [4351772]     Ответить | Цитировать Сообщить модератору
 Re: Динамический SQL. Можно ли обойтись без него.  [new]
~~~~~~~~~!
Guest
В Оракле нет статического sql и быть не может, как это есть, скажем в MSSQL хп WITH_NO_RECOMPILE или как там, или тотже informix. Все стейтменты, даже если оно в пакетах, хард-парсятся, софт-парсятся, делается привязка и фетчатся. Единственное отличие пакетов, думается там можно секономить на рекурсивных вызовах на стадии софт-парс, что, в принципе, тоже не плохо :)

Bye
псевдоаналитик, блин
Еще один наивный
1. Перенос формирования запроса в ХП неизбежно приводит к использованию динамического SQL
Любой запрос вне пакета/процедуры - из делфы, например, - может считать себя динамическим.
/* Поправьте меня, люди! */
4 июл 07, 18:28    [4351842]     Ответить | Цитировать Сообщить модератору
 Re: Динамический SQL. Можно ли обойтись без него.  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18373
~~~~~~~~~!
В Оракле нет статического sql и быть не может, как это есть, скажем в MSSQL хп WITH_NO_RECOMPILE или как там, или тотже informix. Все стейтменты, даже если оно в пакетах, хард-парсятся, софт-парсятся, делается привязка и фетчатся.

ИМХО Вы несколько неправы.
Все стейтменты, даже если они в пакетах, хард/софтпарсятся при первом использовании.
Дальнейшая судьба полученных курсоров в руках программиста.
Для часто используемых курсоров нормальный сценарий использования выглядит как

open
parse
bind
fetch
bind
fetch
...
bind
fetch
close
4 июл 07, 19:20    [4352030]     Ответить | Цитировать Сообщить модератору
 Re: Динамический SQL. Можно ли обойтись без него.  [new]
псевдоаналитик, блин
Guest
Еще один наивный
Простите, коллеги, так работы поднавалило, что и почитать форум некогда. :(. Спасибо за ваши ответы.
Итак, попробуем составить общий список недостатков переноса всех запросов в ХП:
1. Перенос формирования запроса в ХП неизбежно приводит к использованию динамического SQL. Это в свою очередь приводит к проблеме применения bind-переменных, одним из решения которой может являться применение контекстов. В результате, получается сложный для написания, восприятия и отладки код. Перестает работать автоматическая проверка кода на корректность на этапе компиляции, перестают работать средства выделения синтаксиса в инструментах...
2. Довольно часто могут встречаться сложные наборы условий формируемые пользователями на клиенте. Для передачи наборов этих условий необходим какой-то, желательно единообразный, механизм/'язык’, что само по себе является непростой и явно лишней проблемой - фактически замена SQL. Язык PL/SQL не очень хорошо приспособлен для разбора таких наборов условий на сервере.
3. Многие изменения требований повлекут за собой изменения, как на стороне клиента, так и на стороне сервера. Например, добавить столбец в грид. Вероятность возникновения именно таких требований (вовлекающих и клиент и сервер) представляется более высокой, нежели вероятность появления задач требующих изменения только на сервере. Хотя, нельзя не признать, что могут появляться случаи изменения только логики запроса и тогда их можно решить только на уровне сервера.
4. Усложняется процесс внесения изменений «на лету» - он потребует отключения пользователей от сервера.
5. Упрощение администрирования (дать права только на один пакет и все) выглядит сомнительным. Вот об этом, конечно, хотелось бы поподробнее.
6. Возникают дополнительные вопросы безопасности – недопущения передачи в ХП каких-либо условий запроса способных нарушить авторизационную модель
Перечитал еще раз... Все слова правильные, а вместе - бред бредом! Хотя бы пункт 1 - противоречит сам себе в каждом слове.
4 июл 07, 20:46    [4352178]     Ответить | Цитировать Сообщить модератору
 Re: Динамический SQL. Можно ли обойтись без него.  [new]
mcureenab
Member

Откуда: Murmansk
Сообщений: 5928
andrey_anonymous
~~~~~~~~~!
В Оракле нет статического sql и быть не может, как это есть, скажем в MSSQL хп WITH_NO_RECOMPILE или как там, или тотже informix. Все стейтменты, даже если оно в пакетах, хард-парсятся, софт-парсятся, делается привязка и фетчатся.

ИМХО Вы несколько неправы.
Все стейтменты, даже если они в пакетах, хард/софтпарсятся при первом использовании.
Дальнейшая судьба полученных курсоров в руках программиста.
Для часто используемых курсоров нормальный сценарий использования выглядит как

open
parse
bind
execute
fetch
bind
execute
fetch
...
bind
execute
fetch
close


В PL/SQL (окромя DBMS_SQL) этот процесс выглядит иначе (PL/SQL'ный open скрывает за собой ala OCI'ные open и parse и bind и execute), и судьба курсоров ускользает в цепкие лапки PL/SQL машины (в том смысле, что PL/SQL избегает ненужных open и parse).
4 июл 07, 22:19    [4352350]     Ответить | Цитировать Сообщить модератору
 Re: Динамический SQL. Можно ли обойтись без него.  [new]
mcureenab
Member

Откуда: Murmansk
Сообщений: 5928
псевдоаналитик, блин
Перечитал еще раз... Все слова правильные, а вместе - бред бредом! Хотя бы пункт 1 - противоречит сам себе в каждом слове.


Почитай всё вместе, а не по словам.
4 июл 07, 22:24    [4352359]     Ответить | Цитировать Сообщить модератору
 Re: Динамический SQL. Можно ли обойтись без него.  [new]
псевдоаналитик, блин
Guest
softwarer
Еще один наивный
5. Упрощение администрирования (дать права только на один пакет и все) выглядит сомнительным. Вот об этом, конечно, хотелось бы поподробнее.
Как правило, "один грант" - дырка в безопасности. Чаще всего требуется, чтобы некий пользователь мог видеть данные, но не мог бы их менять; таким образом, если объединять в одном пакете процедуры выборки и модификации, уже потребуется городить сомнительные собственные велосипеды.
Звучит хорошо... до того момента, когда появляется необходимость разделить доступ (как просмотр, так и изменения) построчно (балсчет/цех/фирма) между пользователями, причем это надо изменяеть во времени (у нас такое в каждом практически операторе / каждой задаче). Тут никакими грантами не сделаешь - только свой велосипед или "тщательный контроль доступа".
4 июл 07, 23:24    [4352428]     Ответить | Цитировать Сообщить модератору
 Re: Динамический SQL. Можно ли обойтись без него.  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 64001
Блог
псевдоаналитик, блин
Звучит хорошо...

И работает тоже.

псевдоаналитик, блин
Тут никакими грантами не сделаешь - только свой велосипед или "тщательный контроль доступа".

Угу. И я даже не сомневаюсь, что следует выбрать.
4 июл 07, 23:56    [4352456]     Ответить | Цитировать Сообщить модератору
 Re: Динамический SQL. Можно ли обойтись без него.  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18373
mcureenab
В PL/SQL (окромя DBMS_SQL)

DBMS_SQL тоже в руках разработчика. Именно его я в первую очередь и имел ввиду.
mcureenab
этот процесс выглядит иначе (PL/SQL'ный open скрывает за собой ala OCI'ные open и parse и bind и execute), и судьба курсоров ускользает в цепкие лапки PL/SQL машины (в том смысле, что PL/SQL избегает ненужных open и parse).

Тут ты сам себе противоречишь - с одной стороны устанавливаешь жесткую связь между PL/SQL open и системными open+parse+bind+execute, с другой - совершенно справедливо эту связь разрушаешь историями про цепкие лапки.
Уж пожалуйста определяйся - а то, как говаривала когда-то моя бабушка, светлая ей память: "Шей да пори - не будет простой поры" :)
Однако доля истины таки есть - реальный контроль над PL-курсорами действительно принадлежит PL/SQL машине и ручка управления выведена скорее в кабинет DBA, нежели в лабораторию девелоперов.
5 июл 07, 12:36    [4354523]     Ответить | Цитировать Сообщить модератору
 Re: Динамический SQL. Можно ли обойтись без него.  [new]
Еще один наивный
Guest
псевдоаналитик, блин
Все слова правильные, а вместе - бред бредом!

Спасибо! Ваше мнение очень ценно для меня!
5 июл 07, 22:21    [4358060]     Ответить | Цитировать Сообщить модератору
 Re: Динамический SQL. Можно ли обойтись без него.  [new]
Maxifly
Member

Откуда:
Сообщений: 522
andrey_anonymous
Еще один наивный
Коллеги, очень интересная тема! Не возражаете ее еще немного продолжить?

<...>
2) Есть такая смешная штука, как SQL injection. Написать ХП, реализующую мощную логику поиска но не допускающую SQL injection - задача далеко не простая. В результате получится либо несопровождаемый, функционально ограниченный монстрик, либо "дырявый" интерфейс. При "обычной" же схеме на стороне клиента пользователь ограничен возможностями предоставленного интерфейса, на стороне сервера работает та самая "сложная" система авторизации, которую пытаются исключить посредством ХП.
<...>


Используя динамический SQL и ХП можно скрыть внутреннюю организацию данных от клиента. Позволив клиенту формировать запросы к БД придется раздать соответсвующие права на объекты БД. Таблицы, вьюхи и т.п. Тут уж и SQL injection не понадобится. Пиши любой запрос и смотри, что хочешь. А то и исправляй, если прав хватит.

PS. Использую динамический SQL + контексты.
6 июл 07, 12:31    [4359857]     Ответить | Цитировать Сообщить модератору
 Re: Динамический SQL. Можно ли обойтись без него.  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 64001
Блог
Maxifly
Используя динамический SQL и ХП можно скрыть внутреннюю организацию данных от клиента.

Мне все еще интересно, почему у такого количества людей "чтение книжек, в том числе дурных" начисто убивает процесс "думать собственными мозгами".
6 июл 07, 12:41    [4359941]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4   вперед  Ctrl      все
Все форумы / Oracle Ответить