Ded wrote:
Roman Rokytskyy wrote:
Например Ты хочешь сделать аналог MERGE или REPLACE (не помню, что там
в Вулкане сейчас) - если строка с PK уже есть, то делать UPDATE, а
если нет - INSERT.
Понятно, можно сделать сначала SELECT, посмотреть нашли ли чего, и
тогда решить. Но, если в 99% случаев будет идти INSERT и только в 1% -
UPDATE, ты будешь вызывать лишний SELECT в 99% случаев, что не есть
эффективно.
А по-моему разработчик приложения лучше знает где у него что
преимущественно, и в функциях преимущественного апдейта его и будет
делать и проверять Row_Count, в случаях преимущественного инсёрта -
инсёртить, ловить эксепшн и проверять именно код, а в среднем случае
поступит как написано на скрижалях ibase. Имхо бессмыссленная это
автоматизация, ловушка для неофита.
SELECT count(*) FROM bla WHERE pk = ? + UPDATE будет эквивалентна соотв.
INSERT+UPDATE только тогда, когда используется isc_exec_immed2 для
селекта, в остальных случаях она генерирует на 2 сетевых пакета больше.
И я имею основания полагать, что isc_dsql_exec_immed2 ни Дельфийскими,
ни Си-шарпнутыми, ни Явушными компонентами в этом случае использоватся
не будет, а все пойдет через isc_dsql_exec2 + isc_dsql_fetch +
isc_dsql_free. Хотя я не могу сказать, что будет работать быстрее на
самом сервере, SELECT или же INSERT, - теор. селект должен быть немного
быстрее.
Но это был только пример для обработки ошибки по условию, может не
совсем удачный. У меня в тест-кейсах к драйверу таблицы создаются
автоматически перед исполнением тест-кейса и после исполнения удаляются.
И та же конструкция используется во время создания таблиц для тестов -
сначала DROP, ели не нашли таблицы - пофиг, а если что-то другое - тогда
ой! И только после этого идет CREATE.
Все, что я хотел сказать, это то, что значительно проще обрабатывать код
ошибки чем текст из firebird.msg, и что есть случаи, когда обработка
кода ошибки имеет смысл.
Роман
- Re: Целесообразность isc_dsql_unprepare? Roman Rokytskyy
-
