Динамическое формирование SELECT - зло?
От: mr_dino  
Дата: 09.06.06 08:36
Оценка:
встретил мысль на форуме, что динамическое формирование SELECT часто представляет неудачное решение.

В моем проекте такое встречается.

Пример загрузки списка объектов по фильтру:

procedure TDataFunctions.LoadEvents(ADateFrom, ADateTo: TDateTime; AType: Integer): ICollection;
begin
  ...

  where := 'DELETED = 0';
  if ADateFrom <> NullDate then
    where := where + ' AND DATEFROM >= :P1';
  if ADateTo <> NullDate then
    where := where + ' AND DATETO =< :P2';
  if AType <> 0 then
    where := where + ' AND EVENTTYPE = :P3';

  sql := 'SELECT ID, EVENT_NAME, DATEFROM, DATETO, EVENTTYPE FROM EVENTS ' + where;
    
    { init params and fetch objects }
  ...
end;


Думаю, идея — понятна. Для некоторых процедур фильтр состоит из 20-30 параметров.

Есть ли более удачные подходы? Кто как делает? Как это решается, когда вся работа с БД строится на хранимых процедурах? Ведь это — проблематично, заранее написать все варинты запросов.

Спасибо.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re: Динамическое формирование SELECT - зло?
От: Miroff Россия  
Дата: 09.06.06 10:53
Оценка:
Здравствуйте, mr_dino, Вы писали:

_>Есть ли более удачные подходы? Кто как делает? Как это решается, когда вся работа с БД строится на хранимых процедурах? Ведь это — проблематично, заранее написать все варинты запросов.


IMHO, основная проблема, которой этот подход может быть череват это размазанность SQL запросов по коду. Соответственно такой "размазаный" SQL труднее модифицировать и читать. Решается это созданием всяческих SQL Builder'ов (классов, инкапсулирующих логику работы с базой данных) либо переходом на какой-нибудь OR mapper.
Re: Динамическое формирование SELECT - зло?
От: wildwind Россия  
Дата: 09.06.06 11:50
Оценка:
Здравствуйте, mr_dino, Вы писали:

_>Думаю, идея — понятна. Для некоторых процедур фильтр состоит из 20-30 параметров.


_>Есть ли более удачные подходы? Кто как делает? Как это решается, когда вся работа с БД строится на хранимых процедурах? Ведь это — проблематично, заранее написать все варинты запросов.


С какой СУБД работаешь?
Re[2]: Динамическое формирование SELECT - зло?
От: mr_dino  
Дата: 09.06.06 12:26
Оценка:
Здравствуйте, Miroff, Вы писали:

M>IMHO, основная проблема, которой этот подход может быть череват это размазанность SQL запросов по коду. Соответственно такой "размазаный" SQL труднее модифицировать и читать. Решается это созданием всяческих SQL Builder'ов (классов, инкапсулирующих логику работы с базой данных) либо переходом на какой-нибудь OR mapper.


Вроде с OR mapper-ом та же проблема. Всеравно надо динамически формировать запрос, только теперь уже на языке OR mapper-а.

Интересно — в примерах от Microsoft один из основных подходов — все делать через хранимые процедуры. Но я не смог представить как написать хранимую процедуру аналогичную примеру выше. Но должен признать, что опыта у меня в этом направлении — маловато.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[2]: Динамическое формирование SELECT - зло?
От: mr_dino  
Дата: 09.06.06 12:32
Оценка:
Здравствуйте, wildwind, Вы писали:

W>Здравствуйте, mr_dino, Вы писали:


_>>Думаю, идея — понятна. Для некоторых процедур фильтр состоит из 20-30 параметров.


_>>Есть ли более удачные подходы? Кто как делает? Как это решается, когда вся работа с БД строится на хранимых процедурах? Ведь это — проблематично, заранее написать все варинты запросов.


W>С какой СУБД работаешь?


Со многими Interbase, MSSQL, Oracle. Но надо проектировать новый продукт. Там будет только MSSQL. Думаю над архитектурой...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re: Динамическое формирование SELECT - зло?
От: IT Россия linq2db.com
Дата: 09.06.06 12:54
Оценка: 1 (1)
Здравствуйте, mr_dino, Вы писали:

_>встретил мысль на форуме, что динамическое формирование SELECT часто представляет неудачное решение.


Но иногда без этого никуда.

_>Есть ли более удачные подходы? Кто как делает? Как это решается, когда вся работа с БД строится на хранимых процедурах? Ведь это — проблематично, заранее написать все варинты запросов.


Если делать генерацию SQL, то лучше на клиенте. SQL не лучший язык для написания какой бы то ни было логики. Да и с отладкой будет меньше проблем.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[2]: Динамическое формирование SELECT - зло?
От: mr_dino  
Дата: 09.06.06 12:57
Оценка:
Здравствуйте, IT, Вы писали:

_>>Есть ли более удачные подходы? Кто как делает? Как это решается, когда вся работа с БД строится на хранимых процедурах? Ведь это — проблематично, заранее написать все варинты запросов.


IT>Если делать генерацию SQL, то лучше на клиенте. SQL не лучший язык для написания какой бы то ни было логики. Да и с отладкой будет меньше проблем.


ОК. Спасибо. Будем считать, что подход — нормальный.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[3]: Динамическое формирование SELECT - зло?
От: Аноним  
Дата: 09.06.06 15:53
Оценка:
Здравствуйте, mr_dino, Вы писали:

_>Здравствуйте, IT, Вы писали:


_>>>Есть ли более удачные подходы? Кто как делает? Как это решается, когда вся работа с БД строится на хранимых процедурах? Ведь это — проблематично, заранее написать все варинты запросов.


IT>>Если делать генерацию SQL, то лучше на клиенте. SQL не лучший язык для написания какой бы то ни было логики. Да и с отладкой будет меньше проблем.


_>ОК. Спасибо. Будем считать, что подход — нормальный.


Для курсовика — вполне ....
Поменяется СУБД ... поменяется клиент?
Вопросы оптимизации запросов тоже через клиента?
Прозрачность транзакций?

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

--
музыка сфер ...
Re[4]: Динамическое формирование SELECT - зло?
От: Аноним  
Дата: 09.06.06 15:55
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, mr_dino, Вы писали:


_>>Здравствуйте, IT, Вы писали:


_>>>>Есть ли более удачные подходы? Кто как делает? Как это решается, когда вся работа с БД строится на хранимых процедурах? Ведь это — проблематично, заранее написать все варинты запросов.


IT>>>Если делать генерацию SQL, то лучше на клиенте. SQL не лучший язык для написания какой бы то ни было логики. Да и с отладкой будет меньше проблем.


_>>ОК. Спасибо. Будем считать, что подход — нормальный.


А>Для курсовика — вполне ....

Забыло сказать про изменение структуры БД ...

--
музыка сфер ...
Re[5]: Динамическое формирование SELECT - зло?
От: Lucker Беларусь http://lucker.intervelopers.com/
Дата: 09.06.06 16:01
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>>Для курсовика — вполне ....

А>Забыло сказать про изменение структуры БД ...

хм, а есть альтернативное решение? Интересно было бы услышать в рамках поставленой задачи.
Re[6]: Динамическое формирование SELECT - зло?
От: Аноним  
Дата: 09.06.06 16:15
Оценка:
Здравствуйте, Lucker, Вы писали:

L>Здравствуйте, <Аноним>, Вы писали:


А>>>Для курсовика — вполне ....

А>>Забыло сказать про изменение структуры БД ...

L>хм, а есть альтернативное решение? Интересно было бы услышать в рамках поставленой задачи.

Условия задачи нам неведомы ....
20-30 параметров в вашем примере мы не увидели ....
кстати .... сигнатуры методов будут такими же резиновыми, как вы предполагаете?

На наш скромный взгляд ... для безболезненного перехода на разные СУБД ....
а также прочего манипулирования с хранилищем ... мы склоняемся к ХП ....
Мейби некоторые ваши проблемы удастца разрулить самой БД (использование view и ты ды) ...

--
нигилистическое хвы
Re[7]: Динамическое формирование SELECT - зло?
От: Lucker Беларусь http://lucker.intervelopers.com/
Дата: 09.06.06 16:26
Оценка:
Здравствуйте, <Аноним>, Вы писали:

L>>хм, а есть альтернативное решение? Интересно было бы услышать в рамках поставленой задачи.

А>Условия задачи нам неведомы ....
А>20-30 параметров в вашем примере мы не увидели ....
А>кстати .... сигнатуры методов будут такими же резиновыми, как вы предполагаете?

не факт. возможно определится один метод с параметром Criteria, содержащим коньюнкцию критериев для поиска.

А>На наш скромный взгляд ... для безболезненного перехода на разные СУБД ....

А>а также прочего манипулирования с хранилищем ... мы склоняемся к ХП ....

а ваш скромный взгляд рассматривает такую СУБД как MySQL, где хранимки появились только в 5-ой версии, и не каждый абмин еще рискнул обновиться?

А>Мейби некоторые ваши проблемы удастца разрулить самой БД (использование view и ты ды) ...


у меня проблем вообще нет. я использую динамически-формируемый sql, и как-то пока жив.
Re[4]: Динамическое формирование SELECT - зло?
От: IT Россия linq2db.com
Дата: 09.06.06 16:39
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Для курсовика — вполне ....


Есть задачи где без генерации в принципе нельзя обойтись. Например, отчёты с drill down функциональностью.
Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: Динамическое формирование SELECT - зло?
От: Аноним  
Дата: 09.06.06 16:53
Оценка:
Здравствуйте, Lucker, Вы писали:

L>Здравствуйте, <Аноним>, Вы писали:


L>не факт. возможно определится один метод с параметром Criteria, содержащим коньюнкцию критериев для поиска.

понакрутить можно все что угодно ... хоть один словарь передавать ...

L>а ваш скромный взгляд рассматривает такую СУБД как MySQL, где хранимки появились только в 5-ой версии, и не каждый абмин еще рискнул обновиться?


---- чик ----
W>С какой СУБД работаешь?

Со многими Interbase, MSSQL, Oracle. Но надо проектировать новый продукт. Там будет только MSSQL. Думаю над архитектурой...
---- чик ----



L>у меня проблем вообще нет. я использую динамически-формируемый sql, и как-то пока жив.

удачи вам ....
Одно непонятно .... к чему ваш вопрос .... от добра добра не ищут ...

Некоторые минусы (которые могут стать существенными) по своему мнению я вам изложило ...
умываю руки ...

--
молчание волн
Re[5]: Динамическое формирование SELECT - зло?
От: Аноним  
Дата: 09.06.06 17:04
Оценка:
Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Аноним, Вы писали:


А>>Для курсовика — вполне ....


IT>Есть задачи где без генерации в принципе нельзя обойтись. Например, отчёты с drill down функциональностью.


Кроме предположений ... о диком количестве параметров ... о задаче ничего неизвестно ....
с отчётами с drill down функциональностью незнакомы (кусает локти).
но знающение люди нам тут вот подсказывают .... OLAP ....

--
хвы
Re[9]: Динамическое формирование SELECT - зло?
От: Lucker Беларусь http://lucker.intervelopers.com/
Дата: 09.06.06 17:13
Оценка:
Здравствуйте, <Аноним>, Вы писали:

L>>а ваш скромный взгляд рассматривает такую СУБД как MySQL, где хранимки появились только в 5-ой версии, и не каждый абмин еще рискнул обновиться?

А>---- чик ----
W>>С какой СУБД работаешь?

А>Со многими Interbase, MSSQL, Oracle. Но надо проектировать новый продукт. Там будет только MSSQL. Думаю над архитектурой...

А>---- чик ----

а к чему тогда

А>На наш скромный взгляд ... для безболезненного перехода на разные СУБД ....


был?

А>Некоторые минусы (которые могут стать существенными) по своему мнению я вам изложило ...

А>умываю руки ...

нет, ну оно понятно, чтог минусы есть. Но как сказали: есть задачи где по-другому просто нельзя, и тогда придется или писать свою версию под каждую субд, что не проблема, если грамотно ражделены слои, или брать готовый ORM и писать динамические запросы на его OQL.
Re[6]: Динамическое формирование SELECT - зло?
От: IT Россия linq2db.com
Дата: 09.06.06 17:19
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>Кроме предположений ... о диком количестве параметров ... о задаче ничего неизвестно ....


Это правда.

А>но знающение люди нам тут вот подсказывают .... OLAP ....


А как ты думаешь в OLAP запросы реализуются? Через SP?
Если нам не помогут, то мы тоже никого не пощадим.
Re[7]: Динамическое формирование SELECT - зло?
От: gbear Россия  
Дата: 09.06.06 17:27
Оценка:
Здравствуйте, IT, Вы писали:

А>>но знающение люди нам тут вот подсказывают .... OLAP ....


IT>А как ты думаешь в OLAP запросы реализуются? Через SP?


Хех... дык OLAP же не на клиенте Или таки на нем? Тем более что, ... ой могу ошибаться... довно это было... но там и не совсем динамические запросы... Все таки срез делается по строга фиксированным параметрам... а уж вот данные из среза можно drillit'ь... Но это не совсем то, что динамик SQL... точнее, это совсем не то...

---
С уважением, Константин Сиваков
Re[8]: Динамическое формирование SELECT - зло?
От: IT Россия linq2db.com
Дата: 09.06.06 17:39
Оценка:
Здравствуйте, gbear, Вы писали:

G>Хех... дык OLAP же не на клиенте


Разве автор топика что-то говорил о клиенте?

G>Или таки на нем?


А если нужна подобная функциональность на нём?

G>Хех... дык OLAP же не на клиенте Или таки на нем? Тем более что, ... ой могу ошибаться... довно это было... но там и не совсем динамические запросы... Все таки срез делается по строга фиксированным параметрам... а уж вот данные из среза можно drillit'ь... Но это не совсем то, что динамик SQL... точнее, это совсем не то...


А что?

Вообще анониму прежде чем критиковать данный подход надо было либо выяснить у автора топика некоторые интимные подробности, либо самому обозначить круг задач, которые он имеет ввиду. Я лично сам всеми руками и ногами за спроки. Но вот иногда попадаются задачи, где SQL лучше генерировать.
Если нам не помогут, то мы тоже никого не пощадим.
Re: Динамическое формирование SELECT - зло?
От: ika Беларусь  
Дата: 09.06.06 20:26
Оценка:
Здравствуйте, mr_dino, Вы писали:

_>встретил мысль на форуме, что динамическое формирование SELECT часто представляет неудачное решение.

_>В моем проекте такое встречается.

Добавлю свои пять копеек.
Я вижу динамическое формирование SQL как вариант увеличения производительности приложения. Понятно, что если запрос формируется динамически, то код, который это делает, является разбросанным. Часто даже куски такого кода находятся в разных функциональных модулях приложения. Но подобная децентрализация формирования запросов позволяет достичь существенных результатов. Пример — табличное представление списка документов (ессно с возможностью постраничной навигации, сортировкой, опцией jumpto и т.д.). В зависимости от того, что юзер щелкает на гуях, запрос получает то или иное navigation clause. Хибернейт врядли умеет правильно и оптимально сам построить подобные запросы. У него другая роль.

Теперь насчет хранимых процедур. В идеале — весь код по работе с хранилищем данных лучше бы запихнуть в саму базу, то есть в процедуры. Они и прекомпилированы (то есть не разбираются заново при каждом обращении), и просто количество трафа ниже — нужно передать только параметры, ибо сам код уже в базе. Но это в идеале. Если система состоит из модулей, то часто нужно, например, к основной процедуре вставки бизнес-объекта в базу (разложить по нескольким табличкам), выполнить еще и сохранение какого-нить функционального "расширения" этого объекта, принесенного дополнительным модулем. Если без процедур — все просто: выполняешь по очереди запросы на сохранение из каждого модуля и все. Хранимая же процедура должна бы в таком случае владеть конфигурацией приложения. То есть, по сути, кроме своей основной задачи, выполнять еще и роль контроллера какого-то. Впрочем, если напрячься, то это наверное не является препятствием. Просто каждый модуль вместо выполнения своих запросов просто вызывает "свои" процедуры с передачей им module-specific параметров. Подход кажется вполне рабочим, только я пока не пробовал так делать.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.