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

Очень Злой (2012-11-08 15:32:00) [1]
Не знаю что для подобного лучше, но на практике, мне когда встречалась такая ситуация, обычно оказывалось что нужные данные есть в других таблицах, из которых их можно получить или напрямую или создать запрос (или представление).., чтобы оно возвращало нечто типа:

item_id item_queue 713 8 24 16 119 24 1028 32 2 40

а тогда уже :
UPDATE table a SET a.item_queue = (select item_queue from dict_table_or_view where item_id=a.item.id)

MsGuns (2012-11-06 13:18:00) [2]
ИМХО, для подобного ХП надо

AlphaHuman (2012-11-06 11:18:00) [3]

> Одной строчкой всё делается, вообще без параметров.
> UPDATE table SET item_queue = item_id * 8

1, 2, 3, 4, 5 - плохой пример привел, реально там может быть: 713, 24, 119, 1028, 2. В итоге должно получиться:

item_id item_queue
713 8
24 16
119 24
1028 32
2 40

Ega23 (2012-11-06 11:11:00) [4]

> А если нужно сделать массовый UPDATE, наример:
>
> UPDATE table SET item_queue =
> CASE item_id
> WHEN item_id = 1 THEN 8
> WHEN item_id = 2 THEN 16
> WHEN item_id = 3 THEN 24
> WHEN item_id = 4 THEN 32
> WHEN item_id = 5 THEN 40
> ...
> WHEN item_id = I THEN J
> END
> WHERE item_id IN (1, 2, 3, 4, 5, ..., I)
>
>
> Нужно создать кучу параметров?

Одной строчкой всё делается, вообще без параметров.
UPDATE table SET item_queue = item_id * 8

AlphaHuman (2012-11-06 11:05:00) [5]
это чтобы избежать множества UPDATE в цикле. Я получаю идентификаторы категорий - item_id. Для каждой категории нужно задать значение поля item_queue (для каждого последующего его значение равно + 8).

Inovet (2012-11-06 10:51:00) [6]
> [44] AlphaHuman (06.11.12 10:47)
> А если нужно сделать массовый UPDATE

Массовый апдейт или исключение для испраления косяков, или что-то не так с архитектурой.

AlphaHuman (2012-11-06 10:47:00) [7]

> Anatoly Podgoretsky © (05.11.12 22:42) [41]
> > kilkennycat (05.11.2012 21:50:38) [38]
>
> Это значит, что не надо замусоривать кеш. Делать все с параметрами
> и всего
> делов.

А если нужно сделать массовый UPDATE, наример:

UPDATE table SET item_queue = CASE item_id WHEN item_id = 1 THEN 8 WHEN item_id = 2 THEN 16 WHEN item_id = 3 THEN 24 WHEN item_id = 4 THEN 32 WHEN item_id = 5 THEN 40 ... WHEN item_id = I THEN J END WHERE item_id IN (1, 2, 3, 4, 5, ..., I)

Нужно создать кучу параметров?

sniknik (2012-11-05 23:00:00) [8]
> Догмы навязываете-с.
+1
а ну как, условия нет, параметр придумать?

> Сервер Firebird (2.5 кажется). Компоненты доступа DBX.
они также как ADO делают при возможности (коннект + не определенность) обращение на сервер определяя тип и валидность параметров?

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

нельзя использовать на всем один подход.

DVM (2012-11-05 22:45:00) [9]

> Anatoly Podgoretsky © (05.11.12 22:42) [41]

> Делать все с параметрами и всего
> делов.
>
>

Догмы навязываете-с.

Anatoly Podgoretsky (2012-11-05 22:42:00) [10]
> kilkennycat (05.11.2012 21:50:38) [38]

Это значит, что не надо замусоривать кеш. Делать все с параметрами и всего
делов.

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

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

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

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

sniknik (2012-11-05 21:55:00) [12]
> Сервер запрос исполнял намного дольше.
речь не разовом запросе, а о данном подходе при массовых вставках например. при разовом когда препаре запроса + определение/внос параметра пусть сотую долю секунды выполняется, естественно не сильно влиеят на секундное например выполнение самого запроса.

kilkennycat (2012-11-05 21:50:00) [13]

> Anatoly Podgoretsky © (05.11.12 21:46) [37]

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

Anatoly Podgoretsky (2012-11-05 21:46:00) [14]
> DVM (05.11.2012 21:32:33) [33]

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

DVM (2012-11-05 21:43:00) [15]

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

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

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

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

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

sniknik (2012-11-05 21:36:00) [16]
> но имхо на клиенте это ловля блох при единичных запросах.
ну да, а после "специально обученные" начинают это "как есть" в миллионные циклы вставлять. сорри, сам отступил от конкретики.

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

sniknik (2012-11-05 21:33:00) [17]
> Использовать параметры всегдаесть смысл
в данной теме, вроде бы 2-й случай, но внос параметра спарен с вносом запроса, в "специальном методе"... т.е. все одноразовое, т.е. вывод -
> в результате ускорение самого запроса и меньшая потеря ресурсов.
не к нему. смысла в подходе (что в теме) нет.

DVM (2012-11-05 21:32:00) [18]

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

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

DVM (2012-11-05 21:29:00) [19]

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

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

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

sniknik (2012-11-05 21:25:00) [20]
> в каких грехах я обвиняюсь?
создание и распространение догм.

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

Наверх

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