скорость

← →
race1 (2002-12-30 14:38) [0]

если писать процедуру в дельфях и писать ХП, то разница в производительности будет заметна? количество записей не большое - около 200

← →
Max Zyuzin (2002-12-30 14:41) [1]

Все зависит от того, что будет делать процедура :)
Но априоре считается, что сервер более мощная машина + не нужно тащить информацию на клиента, затем ее обрабатывать, -> ХП будет работать быстрее...

← →
Delirium^.Tremens (2002-12-30 14:42) [2]

> если писать процедуру в дельфях и писать ХП, то разница
> в производительности будет заметна? количество записей не
> большое - около 200

Еще один крендель, который потом еще начнет брыкаться и говорить, что здесь "НЕПРОГРАММЕРЫ"

← →
passm (2002-12-30 14:43) [3]

race1 © (30.12.02 14:38)> IMHO определяется задачей в частном порядке.

← →
Digitman (2002-12-30 16:35) [4]

> race1

Только один комментарий - в run-time blr-код SP/view/триггера исполняется сервером в режиме интерпретации. Имей это ввиду.

← →
passm (2002-12-30 16:43) [5]

Digitman © (30.12.02 16:35)> Зависит от СУБД!

← →
Digitman (2002-12-30 17:54) [6]

> passm

Назови СУБД, в которой SP исполняется не интерпретатором

← →
ORACLE (2002-12-30 18:00) [7]

>Digitman © (30.12.02 17:54)

ORACLE

← →
passm (2002-12-30 18:05) [8]

Digitman © (30.12.02 17:54)> DB2

← →
OlegE (2002-12-30 18:06) [9]

У меня при конкретной реализации в 4 случаях - процедура быстрее, а в 4 четырех - медленнее.
Поэтому первые 4 - реализация - в ХП,
вторые 4 - реализация на клиенте.
Дошел до этого опытным путем, т.е. через 4 месяца 2 ХП заменил на обработку на клиенте, 1 обработку - с клиента перенес в ХП.
Рекомендую проверить твою реализацию и так и так, уверен выбирешь правильное решение.
...Опыт - сын ошибок трудных...

← →
Prooksius (2002-12-30 18:07) [10]

>Digitman ©
IB/FB/YA
Там сразу компилится.

← →
Digitman (2002-12-31 08:28) [11]

"Компилится" не значит, что в результате формируется "исполняемый" код. Результатом такой "компиляции" явл-ся некий токенизированный код (в IB/FB/YA - т.н. BLR-код, Binary Lanquage Representation), на основе которого в run-time строится дерево запроса, токен-узлы которого, собственно, и интерпретируются. Более того, в run-time перед исполнением запроса его хранимый blr-код преобразуется в request tree тоже в результате "компиляции")
С достаточной долей уверенности могу предположить, что эти механизмы присутствуют в том или ином виде и в DB2 и ORACLE и в MS SQL. Разница лишь во внутреннем представлении токенизированного кода запроса в той или иной СУБД (и терминах, фигурирующих по воле разработчиков для прямого и обратного преобразования кода запросов)

Посудите сами - разве можно восстановить текст SP (например, для резервного хранения скрипта базы), если эта самая SP "скомпилирована" до уровня "безымянных" маш.п/программ ?
По аналогии можно сказать, что т.н. "компилятор" для VisualBasic-проектов тоже вроде бы "компилит"-"линкует" (как и положено для генерации PE-модулей), но в любой момент времени такой VB PE-модуль можно декомпилировать до уровня практически идентичного исх.тексту. Для подобного рода сред это лишний раз говорит о том, что результатом такой "компиляции" явл-ся именно токен-код, интерпретируемый в run-time с той или иной степенью производительности и эффективности (зависит от конкр.платформы и "изобретательности" ее разработчиков, будь то ORACLE или IB или черт те что и сбоку бантик :) )

← →
Sergey Masloff (2002-12-31 08:51) [12]

>Digitman
>Посудите сами - разве можно восстановить текст SP (например, >для резервного хранения скрипта базы), если эта самая >SP "скомпилирована" до уровня "безымянных" маш.п/программ ?
ну вот тут Вы не правы. Какое "восстановление" текста при b/r? В базе хранится как blr так и сам текст процедуры в текстовом виде. И текс процедуры можно из базы удалить, оставив только blr. По которому восстановить исходный текст может и можно, но это будет практически декомпиляция, и полученый текст (если удастся декомпилировать) будет весьма далек от исходного.
Кстати, удаление текста процедуры никак не повлияет на возможность backup/restore, а вот extract metadata для нее сделать уже не удастся.

А в остальном, конечно, я согласен - blr исполняется интерпретатором.

← →
Digitman (2002-12-31 09:03) [13]

> Sergey Masloff

Я имел ввиду именно extract metadata, а не bakup/restore

> По которому восстановить исходный текст может и можно, но
> это будет практически декомпиляция, и полученый текст (если
> удастся декомпилировать) будет весьма далек от исходного

Ненамного дальше, чем в результате декомпиляции того же VB токен-кода. Здесь важно, что идент-ры из исх.текста запроса после "компиляции" хранятся и в blr-коде. А это - оч важный момент для декомпиляции. Другой вопрос, что blr-код хранит и технологические токены, такие, например, как "begin savepoint/end savepoint", которые, разумеется, в исх.тесте PSQL-предложений не фигурируют. Но это отнюдь не говорит о том, что, имея лишь blr, исходный PSQL-текст нельзя восстановить в оригинале - с тестовыми идентификаторами, ссылками и пр.)

← →
Johnmen (2002-12-31 09:13) [14]

"Преподавателю приятно говорить о том, что он хорошо знает, а не отвечать на поставленный вопрос" © (А.А. Нечаев)

← →
Digitman (2002-12-31 10:15) [15]

А для ответа на поставленный вопрос необходимо знать, какая логика и какие вспомогательные прогр.технологии используются на кл.стороне, а также, наличие возможного выноса части логики в UDF. Например, какие компоненты прямого доступа задействованы, как организовано получение рабочих НД и насколько эффективно организован доступ к ним в ВАП кл.процесса. Ибо здесь всплывает вопрос оптимального баланса между траффиком (хост клиента - хост сервера) и производительностью того или иного кода, исполняемого на той или иной стороне.

Смещение акцента на обработку нескольких (логически зависимых) НД в сторону ВАП клиента ведет к увеличению не только производительности обработки, но и траффика (из-за увеличения числа промежуточных сетевых запросов к серверу и числа возможно возвращаемых им промеж.результатов)

Минимизация кл.логики с соотв. ее переносом в ВАП сервера (в SP/Views/триггеры) минимизирует траффик, но и влечет за собой уменьшение произв-ти кода, реализующего ту же логику, но исполняемого уже в режиме интерпретации.

Оптимальное решение во многих случаях дает 3-хзвенная архитектура построения распред.приложений БД. Если AppServer процесс (2-е, промеж.звено) работает на той же машине и в том же сеансе ОС, что и сервер СУБД, то во многих случаях потери на траффике удается неплохо скомпенсировать установкой лок.коннекта между AppServer"ом и сервером СУБД (при этом транспорт между этими процессами в случае, например, с IB/FB/YA организуется с ипользованием memory mapping - механизма, что значительно эффективней любого сетевого транспорта). В то же время код AppServer"a централизует бизнес-логику и способен исполнять ее непосредственно в маш.коде (если, конечно, AppServer построен в каком-нибудь VB), избавляя тем самым сервер СУБД от необходимости исполнять ту же "навороченную" логику в режиме интерпретации.

← →
Prooksius (2002-12-31 10:16) [16]

> Johnmen © (31.12.02 09:13)
;)
А вообще-то то, о чем Digitman говорит, как о выполнении ХП интерпретатором, будет выполняться достаточно быстро, тем более, что сервер быстрый.

Всех с НОВЫМ ГОДОМ!!!

← →
Digitman (2002-12-31 10:19) [17]

> если, конечно, AppServer построен в НЕ каком-нибудь VB

))

← →
Novice (2002-12-31 10:57) [18]

2 Digitman © (31.12.02 10:15)

> при этом транспорт между этими процессами в случае, например,
> с IB/FB/YA организуется с ипользованием memory mapping

Нельзя ли по-подробнее. Очень интересно.

← →
Digitman (2002-12-31 12:11) [19]

Что "поподробней" ? Как это реализовано изнутри (1) или как задействовать этот режим программно (2)?

(1) - тебя как прикладного программера это волновать не должно, этим занимается run-time-связка между загруженными (в ВАП взаимодействующих процессов) модулями ib/fb/yaserver.exe + gds32.dll(fbclient.dll)

(2) - в кл.приложении просто используй строку коннекта, соответствующую требованиям лок.коннекта, т.е. без использования префиксов (\\ComputerName\.... - для NetBios, HostName:... - для TCP и т.д. в соответствии с док-цией на конкр.СУБД). Включение в строку коннекта префикса, указывающего координаты IB-сервера в сети, заставляет кл.часть СУБД выполнить попытку коннекта к серв.части с использованием конкретного сетевого протокола (зависит от конкретного формата строки коннекта)

Пример :
"LOCALDEVICE:\LOCALPATH\SOMEBASE.GDB" - попытка лок.коннекта

"LOCALHOST:LOCALDEVICE:\LOCALPATH\SOMEBASE.GDB" - попытка коннекта c использованием протокола TCP, несмотря на то, что LOCALHOST = 127.0.0.1 - т.е. один и тот же лок.хост, где работают и кл. и серв. части

← →
Novice (2002-12-31 12:44) [20]

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

← →
Digitman (2002-12-31 12:51) [21]

Так ведь исходники-то открыты !)
По кр.мере - IB6 и FB

Как тебе в 2-х словах-то сказать ?

Бери WinCVS, качай их под "anonymous" с sourceforge.net да изучай на здоровье)... Все там ясно и понятно, комментариев хватает

FB RootPath = cvs.sourceforge.net/cvsroot/firebird

← →
Novice (2002-12-31 15:33) [22]

скорость Найти похожие ветки