Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

нужен ли try..exept

Страницы: < 1 2 3 >
AlphaHuman © (2012-11-05 16:36:00)
Часто в исходниках в инете стал встречать такого плана код:

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. Хотелось бы услышать ваше мнение.

Anatoly Podgoretsky (2012-11-05 21:23:00) [21]
> DVM (05.11.2012 21:09:27) [27]

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

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

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

DVM (2012-11-05 21:20:00) [22]

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

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

sniknik (2012-11-05 21:16:00) [23]
> посмотри в пост [10]
ответ, и спор начался с
DVM © (05.11.12 18:50) [12]
где я что отвечал на [10]?

DVM (2012-11-05 21:09:00) [24]

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

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

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

sniknik (2012-11-05 21:03:00) [25]
> что в данном случае не важно.
что значит не важно если я писал и не однократно подчеркивал именно конкретный случай, ничего другого, а ты начал "опровергать", значит важно.

DVM (2012-11-05 20:51:00) [26]

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

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

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

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

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

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

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

sniknik (2012-11-05 20:44:00) [27]
> достаточно представить себе блоб одним из параметров.
не будем ничего представлять!!! речь либо про конкретику, вопрос темы, либо "ни о чем", так "потрындеть".

sniknik (2012-11-05 20:42:00) [28]
> я знаю как это работает
т.е. то что "это ОДНО ИЗ предназначений параметров" не самообман, а обман? ;(

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

DVM (2012-11-05 20:35:00) [29]

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

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

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

Anatoly Podgoretsky (2012-11-05 20:23:00) [30]
Параметры не часть запроса, они передаются отдельно и не интерпритируются.

DVM (2012-11-05 19:47:00) [31]

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

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

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

DVM (2012-11-05 19:43:00) [32]

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

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

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

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

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

sniknik (2012-11-05 19:42:00) [33]
> Это ОДНО ИЗ предназначений параметров - подставлять нужные значения в заданные места строки запроса.
похоже для тебя будет открытием то что сейчас скажу...
значения параметров в запрос не подставляются. это не аналог Format-а, иначе не было бы препаре, "компиляции" запроса отдельно от параметров, возможности использования одного запроса без перекомпиляции для разных параметров.
вообще параметр это обьект.

sniknik (2012-11-05 19:34:00) [34]
> Не понял вопроса.
мы говорим по теме или уже про коня в вакууме?
я отвечал на -
> Внутри метода создается объект типа TQuery, который должен возвращать записи у которых поле parent_id равно переданному значению:
ты привел мой ответ и сказал что тоже делаешь так же, без всяких нюансов, просто также. вот я я предположил/спросил, ты делаешь так везде, и просто потому, что написал подобный метод?

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

DVM (2012-11-05 19:32:00) [35]

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

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

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

DVM (2012-11-05 19:27:00) [36]

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

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

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

sniknik (2012-11-05 19:17:00) [37]
> И я бы не сказал что от параметров толку совсем никакого.
а я что такое говорил? поищи по форуму, сколько тот моих сообщений "используй параметры"... но не потому что "круто", а потому, что для чего то. ну например для сложно определенного (сам такие упоминал), для избавления от необходимости конвертировать с зависимостью от локальных настроек, для того чтобы один запрос без перепарса использовать много раз...
т.е использовать со смыслом. тут смысла нет.

sniknik (2012-11-05 19:06:00) [38]
> а я вот тоже создаю в рантайм всякие TAdoCommand TAdoDataSet и прочее.
просто так, ни с того ни чего? написал типа метод, и пихаешь него все, потому что он есть? - ССЗБ

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

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

DVM (2012-11-05 18:50:00) [39]

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

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

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

sniknik (2012-11-05 18:42:00) [40]
> как будет правильнее
"правильнее вообще" не бывает, бывает только для чего то конкретного, в описанном тобой, параметр не используется для того для чего предназначен, т.е. будет пофигу что он есть что его нет.
неправилен тут сам подход ... вот > "Внутри метода создается объект типа TQuery, который должен возвращать ..."
зачем создается? зачем метод? что за "спички" которые требуется экономить? память? почему не просто положить нужный компонент на форму/датамодуль, прописать запрос в нем и менять только параметр? (вот тут он будет к месту)
???

Страницы: < 1 2 3 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »