встретил мысль на форуме, что динамическое формирование 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 параметров.
Есть ли более удачные подходы? Кто как делает? Как это решается, когда вся работа с БД строится на хранимых процедурах? Ведь это — проблематично, заранее написать все варинты запросов.
Здравствуйте, mr_dino, Вы писали:
_>Есть ли более удачные подходы? Кто как делает? Как это решается, когда вся работа с БД строится на хранимых процедурах? Ведь это — проблематично, заранее написать все варинты запросов.
IMHO, основная проблема, которой этот подход может быть череват это размазанность SQL запросов по коду. Соответственно такой "размазаный" SQL труднее модифицировать и читать. Решается это созданием всяческих SQL Builder'ов (классов, инкапсулирующих логику работы с базой данных) либо переходом на какой-нибудь OR mapper.
Здравствуйте, mr_dino, Вы писали:
_>Думаю, идея — понятна. Для некоторых процедур фильтр состоит из 20-30 параметров.
_>Есть ли более удачные подходы? Кто как делает? Как это решается, когда вся работа с БД строится на хранимых процедурах? Ведь это — проблематично, заранее написать все варинты запросов.
Здравствуйте, Miroff, Вы писали:
M>IMHO, основная проблема, которой этот подход может быть череват это размазанность SQL запросов по коду. Соответственно такой "размазаный" SQL труднее модифицировать и читать. Решается это созданием всяческих SQL Builder'ов (классов, инкапсулирующих логику работы с базой данных) либо переходом на какой-нибудь OR mapper.
Вроде с OR mapper-ом та же проблема. Всеравно надо динамически формировать запрос, только теперь уже на языке OR mapper-а.
Интересно — в примерах от Microsoft один из основных подходов — все делать через хранимые процедуры. Но я не смог представить как написать хранимую процедуру аналогичную примеру выше. Но должен признать, что опыта у меня в этом направлении — маловато.
Здравствуйте, wildwind, Вы писали:
W>Здравствуйте, mr_dino, Вы писали:
_>>Думаю, идея — понятна. Для некоторых процедур фильтр состоит из 20-30 параметров.
_>>Есть ли более удачные подходы? Кто как делает? Как это решается, когда вся работа с БД строится на хранимых процедурах? Ведь это — проблематично, заранее написать все варинты запросов.
W>С какой СУБД работаешь?
Со многими Interbase, MSSQL, Oracle. Но надо проектировать новый продукт. Там будет только MSSQL. Думаю над архитектурой...
Здравствуйте, mr_dino, Вы писали:
_>встретил мысль на форуме, что динамическое формирование SELECT часто представляет неудачное решение.
Но иногда без этого никуда.
_>Есть ли более удачные подходы? Кто как делает? Как это решается, когда вся работа с БД строится на хранимых процедурах? Ведь это — проблематично, заранее написать все варинты запросов.
Если делать генерацию SQL, то лучше на клиенте. SQL не лучший язык для написания какой бы то ни было логики. Да и с отладкой будет меньше проблем.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, 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[6]: Динамическое формирование SELECT - зло?
От:
Аноним
Дата:
09.06.06 16:15
Оценка:
Здравствуйте, Lucker, Вы писали:
L>Здравствуйте, <Аноним>, Вы писали:
А>>>Для курсовика — вполне .... А>>Забыло сказать про изменение структуры БД ...
L>хм, а есть альтернативное решение? Интересно было бы услышать в рамках поставленой задачи.
Условия задачи нам неведомы ....
20-30 параметров в вашем примере мы не увидели ....
кстати .... сигнатуры методов будут такими же резиновыми, как вы предполагаете?
На наш скромный взгляд ... для безболезненного перехода на разные СУБД ....
а также прочего манипулирования с хранилищем ... мы склоняемся к ХП ....
Мейби некоторые ваши проблемы удастца разрулить самой БД (использование view и ты ды) ...
Здравствуйте, <Аноним>, Вы писали:
L>>хм, а есть альтернативное решение? Интересно было бы услышать в рамках поставленой задачи. А>Условия задачи нам неведомы .... А>20-30 параметров в вашем примере мы не увидели .... А>кстати .... сигнатуры методов будут такими же резиновыми, как вы предполагаете?
не факт. возможно определится один метод с параметром Criteria, содержащим коньюнкцию критериев для поиска.
А>На наш скромный взгляд ... для безболезненного перехода на разные СУБД .... А>а также прочего манипулирования с хранилищем ... мы склоняемся к ХП ....
а ваш скромный взгляд рассматривает такую СУБД как MySQL, где хранимки появились только в 5-ой версии, и не каждый абмин еще рискнул обновиться?
А>Мейби некоторые ваши проблемы удастца разрулить самой БД (использование view и ты ды) ...
у меня проблем вообще нет. я использую динамически-формируемый sql, и как-то пока жив.
Здравствуйте, Аноним, Вы писали:
А>Для курсовика — вполне ....
Есть задачи где без генерации в принципе нельзя обойтись. Например, отчёты с 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 ....
Здравствуйте, <Аноним>, Вы писали:
L>>а ваш скромный взгляд рассматривает такую СУБД как MySQL, где хранимки появились только в 5-ой версии, и не каждый абмин еще рискнул обновиться? А>---- чик ---- W>>С какой СУБД работаешь?
А>Со многими Interbase, MSSQL, Oracle. Но надо проектировать новый продукт. Там будет только MSSQL. Думаю над архитектурой... А>---- чик ----
а к чему тогда
А>На наш скромный взгляд ... для безболезненного перехода на разные СУБД ....
был?
А>Некоторые минусы (которые могут стать существенными) по своему мнению я вам изложило ... А>умываю руки ...
нет, ну оно понятно, чтог минусы есть. Но как сказали: есть задачи где по-другому просто нельзя, и тогда придется или писать свою версию под каждую субд, что не проблема, если грамотно ражделены слои, или брать готовый ORM и писать динамические запросы на его OQL.
Здравствуйте, IT, Вы писали:
А>>но знающение люди нам тут вот подсказывают .... OLAP ....
IT>А как ты думаешь в OLAP запросы реализуются? Через SP?
Хех... дык OLAP же не на клиенте Или таки на нем? Тем более что, ... ой могу ошибаться... довно это было... но там и не совсем динамические запросы... Все таки срез делается по строга фиксированным параметрам... а уж вот данные из среза можно drillit'ь... Но это не совсем то, что динамик SQL... точнее, это совсем не то...
Здравствуйте, gbear, Вы писали:
G>Хех... дык OLAP же не на клиенте
Разве автор топика что-то говорил о клиенте?
G>Или таки на нем?
А если нужна подобная функциональность на нём?
G>Хех... дык OLAP же не на клиенте Или таки на нем? Тем более что, ... ой могу ошибаться... довно это было... но там и не совсем динамические запросы... Все таки срез делается по строга фиксированным параметрам... а уж вот данные из среза можно drillit'ь... Но это не совсем то, что динамик SQL... точнее, это совсем не то...
А что?
Вообще анониму прежде чем критиковать данный подход надо было либо выяснить у автора топика некоторые интимные подробности, либо самому обозначить круг задач, которые он имеет ввиду. Я лично сам всеми руками и ногами за спроки. Но вот иногда попадаются задачи, где SQL лучше генерировать.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, mr_dino, Вы писали:
_>встретил мысль на форуме, что динамическое формирование SELECT часто представляет неудачное решение. _>В моем проекте такое встречается.
Добавлю свои пять копеек.
Я вижу динамическое формирование SQL как вариант увеличения производительности приложения. Понятно, что если запрос формируется динамически, то код, который это делает, является разбросанным. Часто даже куски такого кода находятся в разных функциональных модулях приложения. Но подобная децентрализация формирования запросов позволяет достичь существенных результатов. Пример — табличное представление списка документов (ессно с возможностью постраничной навигации, сортировкой, опцией jumpto и т.д.). В зависимости от того, что юзер щелкает на гуях, запрос получает то или иное navigation clause. Хибернейт врядли умеет правильно и оптимально сам построить подобные запросы. У него другая роль.
Теперь насчет хранимых процедур. В идеале — весь код по работе с хранилищем данных лучше бы запихнуть в саму базу, то есть в процедуры. Они и прекомпилированы (то есть не разбираются заново при каждом обращении), и просто количество трафа ниже — нужно передать только параметры, ибо сам код уже в базе. Но это в идеале. Если система состоит из модулей, то часто нужно, например, к основной процедуре вставки бизнес-объекта в базу (разложить по нескольким табличкам), выполнить еще и сохранение какого-нить функционального "расширения" этого объекта, принесенного дополнительным модулем. Если без процедур — все просто: выполняешь по очереди запросы на сохранение из каждого модуля и все. Хранимая же процедура должна бы в таком случае владеть конфигурацией приложения. То есть, по сути, кроме своей основной задачи, выполнять еще и роль контроллера какого-то. Впрочем, если напрячься, то это наверное не является препятствием. Просто каждый модуль вместо выполнения своих запросов просто вызывает "свои" процедуры с передачей им module-specific параметров. Подход кажется вполне рабочим, только я пока не пробовал так делать.