нужен ли try..exept

← →
AlphaHuman (2012-11-05 16:36) [0]

Часто в исходниках в инете стал встречать такого плана код:

Query.SQL.Text := "SELECT * FROM items WHERE ctg_id=:ctg_id"; try Query.ParamByName("ctg_id").AsInteger = 1; except Query.Params.CreateParam(ftInteger, "ctg_id").AsInteger := 1; end;

Сомневаюсь, что здесь так уж нужен try..exept. Хотелось бы услышать ваше мнение.

← →
kilkennycat © (2012-11-05 17:16) [1]

в таком варианте я тож сомневаюсь. если считать, что все так плохо c ParamByName, то надо идти до конца:
try
Query.ParamByName("ctg_id").AsInteger = 1;
except
try
Query.Params.CreateParam(ftInteger, "ctg_id").AsInteger := 1;
except
showmessage("фигня какая-то")ж
end;
end;

← →
DVM © (2012-11-05 17:23) [2]

> Хотелось бы услышать ваше мнение.

не нужен, как и строка Query.Params.CreateParam(ftInteger, "ctg_id").AsInteger := 1;

← →
sniknik © (2012-11-05 18:00) [3]

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

← →
AlphaHuman (2012-11-05 18:06) [4]

А если так написать:

Query.SQL.Text := Format("SELECT * FROM items WHERE ctg_id=%d", [ctg_id]);

будут существенные отличия в производительности?

← →
sniknik © (2012-11-05 18:08) [5]

> Хотелось бы услышать ваше мнение.
оторванное от контекста выглядит бессмысленно... хотя можно предположить что Query передается извне. например в dll, и это "защита" от не установленного значения для парсера на предмет параметров... ну, т.е. вместо того чтобы проверить признак, тупо присваиваем, и если ошибка то считаем параметр не создан, создаем...
только прикол в том, что для подобного создания параметр нужно определить особо(в ADO так)... ну может в BDE сработает.

неважно, бред это, в любом случае.

← →
sniknik © (2012-11-05 18:09) [6]

> будут существенные отличия в производительности?
> оторванное от контекста ... бред это, в любом случае.

← →
sniknik © (2012-11-05 18:13) [7]

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

← →
RWolf © (2012-11-05 18:15) [8]

[4]
для производительности нужно первым делом выкинуть звёздочку из запроса.

← →
AlphaHuman (2012-11-05 18:19) [9]

Внутри метода создается объект типа TQuery, который должен возвращать записи у которых поле parent_id равно переданному значению:

Нужен ли передавать ParentId в SQL через параметр или можно через спецификатор вывода (%d)?

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

← →
DVM © (2012-11-05 18:37) [10]

> AlphaHuman (05.11.12 18:19) [9]

> Нужен ли передавать ParentId в SQL через параметр или можно
> через спецификатор вывода (%d)?

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

← →
sniknik © (2012-11-05 18:42) [11]

> как будет правильнее
"правильнее вообще" не бывает, бывает только для чего то конкретного, в описанном тобой, параметр не используется для того для чего предназначен, т.е. будет пофигу что он есть что его нет.
неправилен тут сам подход ... вот > "Внутри метода создается объект типа TQuery, который должен возвращать ..."
зачем создается? зачем метод? что за "спички" которые требуется экономить? память? почему не просто положить нужный компонент на форму/датамодуль, прописать запрос в нем и менять только параметр? (вот тут он будет к месту)
???

← →
DVM © (2012-11-05 18:50) [12]

> sniknik © (05.11.12 18:42) [11]

> зачем создается? зачем метод? что за "спички" которые требуется
> экономить? память? почему не просто положить нужный компонент
> на форму/датамодуль, прописать запрос в нем и менять только
> параметр? (вот тут он будет к месту)

а я вот тоже создаю в рантайм всякие TAdoCommand TAdoDataSet и прочее. И тоже как автор вопроса в рантайм присваиваю запрос и параметры. И я бы не сказал что от параметров толку совсем никакого. Во-первых, не надо мудрить с самой строкой запроса, пытаясь вручную туда подставить переменные, а иногда в случае блобов это и невозможно, экранирование опять же, преобразование дат и времени к нужному виду и.т.д. А всякие датамодули и накиданные на них компоненты в диком количестве не люблю. И искать неудобно и контроль теряется имхо.

← →
sniknik © (2012-11-05 19:06) [13]

> а я вот тоже создаю в рантайм всякие TAdoCommand TAdoDataSet и прочее.
просто так, ни с того ни чего? написал типа метод, и пихаешь него все, потому что он есть? - ССЗБ

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

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

← →
sniknik © (2012-11-05 19:17) [14]

> И я бы не сказал что от параметров толку совсем никакого.
а я что такое говорил? поищи по форуму, сколько тот моих сообщений "используй параметры"... но не потому что "круто", а потому, что для чего то. ну например для сложно определенного (сам такие упоминал), для избавления от необходимости конвертировать с зависимостью от локальных настроек, для того чтобы один запрос без перепарса использовать много раз...
т.е использовать со смыслом. тут смысла нет.

← →
DVM © (2012-11-05 19:27) [15]

> sniknik © (05.11.12 19:06) [13]

> просто так, ни с того ни чего? написал типа метод, и пихаешь
> него все, потому что он есть? - ССЗБ

Не понял вопроса. Есть БД, в БД есть таблица в таблице интересующие меня данные, которые я хочу получить. Есть некий класс для общения с БД, в нем метод GetMyData(const AId: integer): TMyData; В нем все динамически создается, иногда даже соединение динамически устанавливается делается запрос возвращаются данные. Потом все освобождается. Обращаюсь к методу, получаю данные. Правда есть нюанс, я в основном пишу серверные приложения и такой подход намного удобнее, т.к. обращение к базе зачастую происходит их нескольких потоков и т.д.

← →
DVM © (2012-11-05 19:32) [16]

> sniknik © (05.11.12 19:17) [14]
>

> т.е использовать со смыслом. тут смысла нет

Определенный смысл есть даже тут, смысл точно такой же как использование Format вместо конкатенации строк. Это ОДНО ИЗ предназначений параметров - подставлять нужные значения в заданные места строки запроса.

← →
sniknik © (2012-11-05 19:34) [17]

> Не понял вопроса.
мы говорим по теме или уже про коня в вакууме?
я отвечал на -
> Внутри метода создается объект типа TQuery, который должен возвращать записи у которых поле parent_id равно переданному значению:
ты привел мой ответ и сказал что тоже делаешь так же, без всяких нюансов, просто также. вот я я предположил/спросил, ты делаешь так везде, и просто потому, что написал подобный метод?

> я в основном пишу серверные приложения
я пишу и сервер и клиент, и подходы у меня в них разные. и что? при чем тут вопрос из темы?

← →
sniknik © (2012-11-05 19:42) [18]

> Это ОДНО ИЗ предназначений параметров - подставлять нужные значения в заданные места строки запроса.
похоже для тебя будет открытием то что сейчас скажу...
значения параметров в запрос не подставляются. это не аналог Format-а, иначе не было бы препаре, "компиляции" запроса отдельно от параметров, возможности использования одного запроса без перекомпиляции для разных параметров.
вообще параметр это обьект.

← →
DVM © (2012-11-05 19:43) [19]

> sniknik © (05.11.12 19:34) [17]

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

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

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

Притом что в сервере данный подход (создание TQuery и присвоение ему запроса на лету) более вероятен, чем в клиенте, т.к. зачастую и TQuery и само соединение живет непродолжительное время.

← →
DVM © (2012-11-05 19:47) [20]

> sniknik © (05.11.12 19:42) [18]

> похоже для тебя будет открытием то что сейчас скажу...

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

← →
Anatoly Podgoretsky © (2012-11-05 20:23) [21]

Параметры не часть запроса, они передаются отдельно и не интерпритируются.

← →
DVM © (2012-11-05 20:35) [22]

> Anatoly Podgoretsky © (05.11.12 20:23) [21]

Ну это очевидно, достаточно представить себе блоб одним из параметров. Если конечно исключить всякие экзотические (но встречающиеся, некоторые сервера понимают) варианты с преставлением блоба как HEX строки и передача его в теле запроса.

Справедливости ради, надо заметить, что способ передачи параметров зависит как от компонентов доступа так и от конкретного сервера и клиента. Но в нашем случае речь о TQuery, так что без вариантов.

← →
sniknik © (2012-11-05 20:42) [23]

> я знаю как это работает
т.е. то что "это ОДНО ИЗ предназначений параметров" не самообман, а обман? ;(

а если без него, то объясни смысл разового создания параметра, для разового запроса, т.е. дополнительного объекта, "напряга" системы гораздо круче чем простая "сборка"/конкатенция строк -
"SELECT * FROM items WHERE ctg_id="+IntToStr(ParentId)
при том что никаких возможных проблем, как с датами, строками, числом с плавающей запятой, это не решает. т.е. вообще. кокой в этом смысл? (ты его должен знать раз отстаиваешь), но только не нужно перекидывать на другое (ну типа сервер, использование в другом контексте, цикле (был бы смысл если 1 раз задать запрос и в цикле менять параметр, но тут явно не оно, т.е. параметр "спарен" с внесением запроса) и т.д.).
насчет понятности тоже не факт, одна короткая строка всегда понятнее чем метод описанный где то там, из 5 строк... (если конечно код только твой и только для тебя, и ты этот метод "как отче наш"... не передаешь куда то и не разбираешь подобное)

← →
sniknik © (2012-11-05 20:44) [24]

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

← →
DVM © (2012-11-05 20:51) [25]

> sniknik © (05.11.12 20:42) [23]

> т.е. то что "это ОДНО ИЗ предназначений параметров" не самообман,
> а обман? ;(

Это ровно то, что я написал, не больше и не меньше. Для пользователя TQuery параметры будут "подставлены" в то место запроса, которое он указал. Как это будет реализовано в компоненте доступа неважно.

> а если без него, то объясни смысл разового создания параметра,
> для разового запроса, т.е. дополнительного объекта, "напряга"
> системы гораздо круче чем простая "сборка"/конкатенция строк
> -
> "SELECT * FROM items WHERE ctg_id="+IntToStr(ParentId)

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

> при том что никаких возможных проблем, как с датами, строками,
> числом с плавающей запятой, это не решает. т.е. вообще.
> кокой в этом смысл?

как это не решает, кучу кавычек пихать в запрос уже не надо и то хорошо

← →
sniknik © (2012-11-05 21:03) [26]

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

← →
DVM © (2012-11-05 21:09) [27]

> sniknik © (05.11.12 21:03) [26]

> ничего другого, а ты начал "опровергать", значит важно.

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

← →
sniknik © (2012-11-05 21:16) [28]

> посмотри в пост [10]
ответ, и спор начался с
DVM © (05.11.12 18:50) [12]
где я что отвечал на [10]?

> sniknik © (05.11.12 21:16) [28]

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

> DVM (05.11.2012 21:09:27) [27]

Использовать параметры всегда есть смысл, например чтобы не
перекомпилировать запрос в простейшем случае.
запрос
where a=2
и
where a=3

это два разных запроса, требуется парсинг, перекомпиляция, построение плана
запроса
а запрос
where a=:а

это один запрос и максимум, что нужно – это построения плана по статистике,
в результате ускорение самого запроса и меньшая потеря ресурсов.

> в каких грехах я обвиняюсь?
создание и распространение догм.

> sniknik © (05.11.12 21:25) [31]

> создание и распространение догм.

Я что, кому то свою точку зрения навязываю? Я рассказал как я делаю, рассказал почему. По-моему догмы тут не я наязываю.

> Anatoly Podgoretsky © (05.11.12 21:23) [30]

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

> Использовать параметры всегда есть смысл
в данной теме, вроде бы 2-й случай, но внос параметра спарен с вносом запроса, в "специальном методе"... т.е. все одноразовое, т.е. вывод -
> в результате ускорение самого запроса и меньшая потеря ресурсов.
не к нему. смысла в подходе (что в теме) нет.

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

> Даже если запрос будет выполнятся много раз это все равно будет мало заметно на среднего размера запросах.
позвольте с вами не согласится.

> sniknik © (05.11.12 21:36) [35]

> ну да, а после "специально обученные" начинают это "как
> есть" в миллионные циклы вставлять

я к этому отношения не имею, человек копируя код должен понимать что он делает.

> позвольте с вами не согласится.

У меня как то особенно не получалось достичь сколько нибудь приемлемого прироста. Очень незначительно получалось. Сервер запрос исполнял намного дольше. То ли запросы такие были, то ли сервер, то ли руки.

> DVM (05.11.2012 21:32:33) [33]

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

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

> sniknik © (05.11.12 21:55) [39]

> речь не разовом запросе, а о данном подходе при массовых
> вставках например.

Вот я как раз и делал вставки. Сотни тысяч записей. И замерял время. Разница была, но очень небольшая, считанные секунды, при общем времени минуты. Сервер Firebird (2.5 кажется). Компоненты доступа DBX. Правда данные были весьма объемные, может это сыграло роль. Собственно решил замерять после какой то темы на форуме с твоим участием, где тот же вопрос обсуждался про параметры.

нужен ли try..exept Найти похожие ветки