Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 [7] 8 9 10 11 .. 25   вперед  Ctrl
 Re: Нужна помощь  [new]
DBA-шник
Guest
pkarklin
DBA-шник

Уважаемый pkarklin,
Большинство здравомыслящих людей согласятся, что молодежь надо учить хорошему.
Вот как бы Вы отнеслись к полемике, развернувшейся вокруг:

"Я жил в Голландии, иногда пробовал героин, ощущения приятные. Но я приехал в Россию, здесь
...
...
свободную продажу героина?".

Ни чего не напоминает?


"Хорошему" на догмах не учат.


Догмы? Для молодых все, что написано по "набитым шишкам" - догма.
После продолжительной практики, у меня появилось желание взять издание К. Дж. Дейта, и бить им по голове молодым разработчикам в течении недели. А может 2-х. Чтобы хотя-бы автора запомнили.
26 авг 08, 14:42    [6110016]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
DBA-шник
Вот и определился Ваш порог вхождения в индустрию: у вас неверные знания, что хуже незнания.

Вы даже не потрудились заглянуть в документацию. Управление транзакциями в триггерах ORACLE есть.


Не Вам судить об уровне моих знаний. Но только в автономных: http://www.orafaq.com/faq/can_one_commit_from_within_a_trigger

DBA-шник
Теперь вопрос: вписываться ли в концепцию РСУБД программный продукт, если в контексте приложения у него на все курсоры 1 переменная состояния?


Да что Вы говорите?! Что Вы там про "незнания"...

sp_cursor_list
26 авг 08, 14:44    [6110028]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Dihotom
Member

Откуда:
Сообщений: 453
SergSuper
Dihotom

А теперь давайте предположим, что логика приложения меняется и все подобные документы всё-таки нужно провести, но на величину остатка, а оставшуюся сумму вынести на внебаланс. В случае с откатом в триггере Вам придется найти и изменить все триггеры, которые участвуют в проверке суммы документа (а их в сложных случаях может быть много) и изменить их. В случае же, если эти триггеры бросают исключения, нужно внести изменение в одном единстенном обработчике исключений и не откатывать в нём транзакцию как ранее, а инициировать ввод двух документов в соответствии с изменнной бизнес-логикой.
Давайте не будем уходить в строну. Остаток получается отрицательным, всю транзакцию надо откатить. Что Вы в этом случае делаете?

Допустим, бизнес-логика на данный момент именно такая - остаток < 0 => транзакцию откатываем. Вы в этом случае используете откат в триггере, а я - выброс исключения + его обработчик, в котором откатываю транзакцию. Теперь логика меняется - в зависимости от каких-то условий (хоть время суток) нужно либо откатить, либо в рамках той же транзакции урезать сумму документа. Я в этом случае в своем обработчике добавляю аналих этих дополнительных условий и только. Что делаете Вы?
SergSuper
Dihotom
Что касается многочисленных требований предоставить стандарт на слои в информационной системе. Стандарта нет, но есть мысли умных людей, которым нет предпосылок не доверять: например, Мартин Фаулер "Архитектура корпоративных программных приложений". Если будут ссылки на статьи/книги, указывающие минусы слоистой модели и плюсы других подходов - приводите буду рад ознакомиться.
Выглядит как "я тут купил одну книгу, так там написано что Вы все дураки". Давайте не прикрываться чужими именами, а высказывать свои мысли. Ведь не факт же что Вы эти книги поняли правильно

Стоп. Я привел в свою поддержку (а точнее в поддержку слоистой концепции) мнение авторитетного не в рамках форума, а, не побоюсь сказать, в мире, человека. Ни он, ни я ничего о дураках не говорили. По-крайней мере, я у него этого не нашел (может, невнимательно читал?). Если Вы приведете аналогичный труд в поддержку другой концепции - я с удовольствием ознакомлюсь. Кроме того, в книгах и статься информация, как правило, изложена менее эмоционально, более последовательно и структурированно, чем на форуме.
26 авг 08, 14:45    [6110041]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Dihotom
Любой код кем-то или чем-то запускается. И транзакция тоже. Инициирующий код - это внешний по отношению к транзакции код, который её запускает.


Спросим тщательнее. Приведенный код "весь". Какой еще запускающий?
26 авг 08, 14:46    [6110044]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
DBA-шник

Теперь вопрос: вписываться ли в концепцию РСУБД программный продукт, если в контексте приложения у него на все курсоры 1 переменная состояния?

Ну собственно и Ваш порог вхождения в индустрию определился
26 авг 08, 14:47    [6110063]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Dihotom
Member

Откуда:
Сообщений: 453
pkarklin
Dihotom
Любой код кем-то или чем-то запускается. И транзакция тоже. Инициирующий код - это внешний по отношению к транзакции код, который её запускает.


Спросим тщательнее. Приведенный код "весь". Какой еще запускающий?

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

На этот раз я Вас правильно понял? :)
26 авг 08, 14:52    [6110103]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
hvlad
Именно ! Так почему же триггер должен определять судьбу всей тр-ции (т.е. и других операторов) ?

Правильно, тот, кто написал вызывающий код, а не тот, кто написал триггер.

Дык пусть он и думает ! Об том и речь !
Если он не в состоянии\не приучен думать, то пусть включает XACT_ABORT...


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

2. И тот, который допускает частичное выполнение не будет заворачивать несколько операторов в одну транзакцию.

ЗЫ. По-моему, я уже в пятый раз это повторяю.
26 авг 08, 14:57    [6110139]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Dihotom
Вы имеете ввиду, что, грубо говоря, вся... хм.. "программа" представляет собой одну транзакцию? Начну с того, что случай это вырожденный.
Однако, в этом случае я создам для этой транзакции обработчик исключений, в который помещу логику анализа результатов выполнения операторов транзакции (т.е., собственно, обработку исключений). В привденном вырожденном случае вся обработка будет состоять из одного оператора отката транзакции.

На этот раз я Вас правильно понял? :)


Я имею ввиду, что транзакция - есть транзакция и она - суть самодостаточный код и для нее не нужно дополнительного инициирующего кода. А я однако, скажу SET XACT_ABORT ON.
26 авг 08, 15:00    [6110174]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
DBA-шник
Догмы? Для молодых все, что написано по "набитым шишкам" - догма.
После продолжительной практики, у меня появилось желание взять издание К. Дж. Дейта, и бить им по голове молодым разработчикам в течении недели. А может 2-х. Чтобы хотя-бы автора запомнили.


Что, у дейта так и написано: "Управление транзакциями в триггере - моветон"?
26 авг 08, 15:03    [6110208]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Dihotom
Member

Откуда:
Сообщений: 453
pkarklin
hvlad
Именно ! Так почему же триггер должен определять судьбу всей тр-ции (т.е. и других операторов) ?

Правильно, тот, кто написал вызывающий код, а не тот, кто написал триггер.

Дык пусть он и думает ! Об том и речь !
Если он не в состоянии\не приучен думать, то пусть включает XACT_ABORT...


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

2. И тот, который допускает частичное выполнение не будет заворачивать несколько операторов в одну транзакцию.

ЗЫ. По-моему, я уже в пятый раз это повторяю.


Да, но транзакция вполне допускает ветвление в случае нарушения ограничения целостности. В Вашем же случае эта возможность рубится на корню! Не прошел один оператор - откатим все. А я хочу в транзакции проанализировать - не прошел один оператор, тогда пойдем по другому пути и завершим транзакцию, никоим образом не навредив целостности.
26 авг 08, 15:03    [6110211]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Dihotom
Да, но транзакция вполне допускает ветвление в случае нарушения ограничения целостности. В Вашем же случае эта возможность рубится на корню! Не прошел один оператор - откатим все. А я хочу в транзакции проанализировать - не прошел один оператор, тогда пойдем по другому пути и завершим транзакцию, никоим образом не навредив целостности.


На Ваше "ветвление" я уже отвечал здесь: Нужна помощь Вместо тупой отправки инструкции можно выполнить проверку.

В приведенному Выше примере, можно и так (при отстувии MERGE):

UPDATE ...
IF @@rowcount = 0 INSERT ...
26 авг 08, 15:15    [6110302]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Dihotom
Member

Откуда:
Сообщений: 453
pkarklin
Dihotom
Вы имеете ввиду, что, грубо говоря, вся... хм.. "программа" представляет собой одну транзакцию? Начну с того, что случай это вырожденный.
Однако, в этом случае я создам для этой транзакции обработчик исключений, в который помещу логику анализа результатов выполнения операторов транзакции (т.е., собственно, обработку исключений). В привденном вырожденном случае вся обработка будет состоять из одного оператора отката транзакции.

На этот раз я Вас правильно понял? :)


Я имею ввиду, что транзакция - есть транзакция и она - суть самодостаточный код и для нее не нужно дополнительного инициирующего кода. А я однако, скажу SET XACT_ABORT ON.

Да, я запутал Вас своим "инициирующим кодом" :)
В случае отката в триггере Вы не оставляете шанса транзакции решить, является ли это ограничение фатальным в текущих условиях и нужно выполнить откат или нет. Получается принцип "Любое нарушение целостности - откат". Но ведь транзакция может проанализировать дополнительные условия недоступные триггеру, и успешно завершиться, выполнив другой набор операторов в случае возникновения нарушения целостности при выполнении предыдущего оператора.
P.S.: Поясните, пожалуйста, в двух словах, "SET XACT_ABORT ON" - это что? Я под Oracle'ом сижу.
26 авг 08, 15:15    [6110309]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
hvlad
Member

Откуда:
Сообщений: 11578
pkarklin
hvlad
Именно ! Так почему же триггер должен определять судьбу всей тр-ции (т.е. и других операторов) ?

Правильно, тот, кто написал вызывающий код, а не тот, кто написал триггер.

Дык пусть он и думает ! Об том и речь !
Если он не в состоянии\не приучен думать, то пусть включает XACT_ABORT...


1. Потому, что если я их включил в транзакцию, значит я по определению жду, что они или все выполняттся или все нет.
Или по незнанию\не опытности\лени\уверенности что "этого не может быть" (не о Вас речь, конечно)

pkarklin
В не зависимости, толи триггер сделал роллбэк, тольи из-за установки SET XACT_ABORT ON она свалилась на другой ошибке целостности бд.
Всё, что Вы здесь написали, сводится к одному - мне разрешили не обрабатывать ошибки и я счастлив этому. Ваше право.

pkarklin
2. И тот, который допускает частичное выполнение не будет заворачивать несколько операторов в одну транзакцию.
Как и какие операторы оборачивать в тр-цию диктует бизнес логика, и только она.

pkarklin
ЗЫ. По-моему, я уже в пятый раз это повторяю.
Мне это тоже уже надоело.
26 авг 08, 15:15    [6110311]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54849

pkarklin

транзакция - есть транзакция и она - суть самодостаточный код и для нее
не нужно дополнительного инициирующего кода.

Transactions are ethereal. They come from nowhere and go to nothing.

Жуть.

Posted via ActualForum NNTP Server 1.4

26 авг 08, 15:16    [6110321]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

Bogdanov Andrey wrote:

> То есть вы разрабатываете некое закрытое приложение и навязываете всем
> свои собственные интерфейсы доступа. Флаг в руки.

Клиент и БД - одно приложение. Разве нет ? У вас клиентов много ?
Не, у нас тоже клиентов много разных, но все наши. Чужих нет.

Но промышленные
> стандарты (такие как SQL, например) как раз и созданы для того, чтобы
> обеспечить легкую интеграцию ПО различных производителей. Ваше право

Ржунимагу. Стандарты ! СОЗДАНЫ !
Они созданы чтобы ЛЕГЧЕ ВТЮХАТЬ СВОЮ СУБД лоху-разработчику, и ПОТОМ ОН С НЕЕ БЫ
НИКОГДА НЕ СЛЕЗ !

Posted via ActualForum NNTP Server 1.4

26 авг 08, 15:18    [6110341]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
hvlad
Member

Откуда:
Сообщений: 11578
pkarklin
Вместо тупой отправки инструкции можно выполнить проверку.

В приведенному Выше примере, можно и так (при отстувии MERGE):

UPDATE ...
IF @@rowcount = 0 INSERT ...
И что - тут не может произойти нарушение PK\UK ???
(не хотел продолжать, но не удержался)
26 авг 08, 15:19    [6110344]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

Николай1 wrote:

> А почему это должно быть в одной транзакции, если Вы изначально
> допускаете, что возможно неполное проведение документов???

> Апередил....

+1 !

Posted via ActualForum NNTP Server 1.4

26 авг 08, 15:19    [6110350]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Николай1
Member

Откуда: Москва
Сообщений: 495
Dihotom
pkarklin
hvlad
Именно ! Так почему же триггер должен определять судьбу всей тр-ции (т.е. и других операторов) ?

Правильно, тот, кто написал вызывающий код, а не тот, кто написал триггер.

Дык пусть он и думает ! Об том и речь !
Если он не в состоянии\не приучен думать, то пусть включает XACT_ABORT...


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

2. И тот, который допускает частичное выполнение не будет заворачивать несколько операторов в одну транзакцию.

ЗЫ. По-моему, я уже в пятый раз это повторяю.


Да, но транзакция вполне допускает ветвление в случае нарушения ограничения целостности. В Вашем же случае эта возможность рубится на корню! Не прошел один оператор - откатим все. А я хочу в транзакции проанализировать - не прошел один оператор, тогда пойдем по другому пути и завершим транзакцию, никоим образом не навредив целостности.


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

Выполнять какие-либо действия вне триггера по результатам его "завала", как минимум, странно. Тем более, что "снаружи" придется еще и выяснять причины завала, который могут быть самые разные, не связанные с кодом именно триггера, а, например, с нарушением декларативной целостности. Веселый будет обработчик ошибок....

Кстати, вопрос к знатокам. А всегда ли триггер выполняется _сразу_ после оператора, который приводит к его вызову? Например, в PROGRESS тригеры обычно выполняются при завершении транзакции, (если не побеспокоиться об ином специально), соответственно, говорить о последовательности их вызова тоже не приходится (опять же, если не побеспокоиться об этом специально).
26 авг 08, 15:19    [6110351]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
hvlad
Всё, что Вы здесь написали, сводится к одному - мне разрешили не обрабатывать ошибки и я счастлив этому. Ваше право.


Вы передергиваете! У меня одна обработка ошибки - полный откат транзакции.

hvlad
Мне это тоже уже надоело.


Мне тоже.
26 авг 08, 15:20    [6110352]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Dihotom
Member

Откуда:
Сообщений: 453
pkarklin
Dihotom
Да, но транзакция вполне допускает ветвление в случае нарушения ограничения целостности. В Вашем же случае эта возможность рубится на корню! Не прошел один оператор - откатим все. А я хочу в транзакции проанализировать - не прошел один оператор, тогда пойдем по другому пути и завершим транзакцию, никоим образом не навредив целостности.


На Ваше "ветвление" я уже отвечал здесь: Нужна помощь Вместо тупой отправки инструкции можно выполнить проверку.

В приведенному Выше примере, можно и так (при отстувии MERGE):

UPDATE ...
IF @@rowcount = 0 INSERT ...

Т.е. Вы предлагаете перед каждым действием проверять его на безошибочную выполнимость даже в тех случаях, когда ошибка может возникнуть в 0.01% случаев? К тому же, Вам в каждом таком случае еще нужно обеспечить неизменность данных между проверкой и выполнением действия. Ну, согласитесь, это не есть хороший подход.

Кстати, у меня появился смежный вопрос: активные участники дискуссии, не могли бы Вы "представиться" - Вы администраторы БД или же разработчики-проектировщики? Начну, я - разработчик.
26 авг 08, 15:20    [6110359]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Dihotom
Member

Откуда:
Сообщений: 453
Николай1
Ну, блин, собрались архитекторы.
Долго не мог понять, что во всех этих рассуждениях про выброс исключения не так. Наконец понял.
Если беретесь проверять в триггере бизнес-логику, то ее следует проверять и реализовывать до конца. То есть, если в триггере выполняется проверка на красное сальдо, и, есть варинты корректной обработки такой ситуации, то именно внутри триггера эта ситуация и должна быть обработана. Тогда все получается логично - я делаю изменения данных и, либо получаю завершенную транзакцию, либо получаю откаченную.

Выполнять какие-либо действия вне триггера по результатам его "завала", как минимум, странно. Тем более, что "снаружи" придется еще и выяснять причины завала, который могут быть самые разные, не связанные с кодом именно триггера, а, например, с нарушением декларативной целостности. Веселый будет обработчик ошибок....

Кстати, вопрос к знатокам. А всегда ли триггер выполняется _сразу_ после оператора, который приводит к его вызову? Например, в PROGRESS тригеры обычно выполняются при завершении транзакции, (если не побеспокоиться об ином специально), соответственно, говорить о последовательности их вызова тоже не приходится (опять же, если не побеспокоиться об этом специально).

Ну не обладает триггер всей информацией, необходимой для обработки ошибок. Как Вы себе это представляете? Причины "завала" определяются элементарно - никто не говорит о выбросе одного единственного исключения "Ошибка", какая ошибка возникла, такое исключение и генерируется. Кроме того, у Вас транзакция может состоять из большого числа потенциально опасных оператор. Вы в каждом будете писать код обработки ошибок? У меня такое чувство, что Вы никогда не занимались структурированной обработкой ошибок.
26 авг 08, 15:27    [6110416]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Dihotom
Т.е. Вы предлагаете перед каждым действием проверять его на безошибочную выполнимость даже в тех случаях, когда ошибка может возникнуть в 0.01% случаев?


Скажите мне, в чем принуципиальная разница в коде. Грубо:

INSERT
IF <ИС нарушения PK> UPDATE

и

UPDATE ...
IF @@rowcount = 0 INSERT ...

или скажем:

IF EXISTS()
  UPDATE
ELSE
  INSERT

Это не я предлагая - это Вы предлагаете везде писать обработчики ИС и уходить на другой оператор. Для меня - ошибка в любом из опертаторов транзакции - ее откат.

Dihotom
Кстати, у меня появился смежный вопрос: активные участники дискуссии, не могли бы Вы "представиться" - Вы администраторы БД или же разработчики-проектировщики? Начну, я - разработчик.


За 12 лет работы есть богатый опыт во всех областях.
26 авг 08, 15:28    [6110422]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Николай1
Member

Откуда: Москва
Сообщений: 495
Dihotom
Николай1
Ну, блин, собрались архитекторы.
Долго не мог понять, что во всех этих рассуждениях про выброс исключения не так. Наконец понял.
Если беретесь проверять в триггере бизнес-логику, то ее следует проверять и реализовывать до конца. То есть, если в триггере выполняется проверка на красное сальдо, и, есть варинты корректной обработки такой ситуации, то именно внутри триггера эта ситуация и должна быть обработана. Тогда все получается логично - я делаю изменения данных и, либо получаю завершенную транзакцию, либо получаю откаченную.

Выполнять какие-либо действия вне триггера по результатам его "завала", как минимум, странно. Тем более, что "снаружи" придется еще и выяснять причины завала, который могут быть самые разные, не связанные с кодом именно триггера, а, например, с нарушением декларативной целостности. Веселый будет обработчик ошибок....

Кстати, вопрос к знатокам. А всегда ли триггер выполняется _сразу_ после оператора, который приводит к его вызову? Например, в PROGRESS тригеры обычно выполняются при завершении транзакции, (если не побеспокоиться об ином специально), соответственно, говорить о последовательности их вызова тоже не приходится (опять же, если не побеспокоиться об этом специально).

Ну не обладает триггер всей информацией, необходимой для обработки ошибок. Как Вы себе это представляете? Причины "завала" определяются элементарно - никто не говорит о выбросе одного единственного исключения "Ошибка", какая ошибка возникла, такое исключение и генерируется. Кроме того, у Вас транзакция может состоять из большого числа потенциально опасных оператор. Вы в каждом будете писать код обработки ошибок? У меня такое чувство, что Вы никогда не занимались структурированной обработкой ошибок.


То есть, как это, не обладает????
Есть еще какая-то информация, помимо той, которая "проложена" в базу?
А что с ней происходит потом?
26 авг 08, 15:38    [6110498]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54849

pkarklin

Скажите мне, в чем принуципиальная разница в коде. Грубо:

Скорость. Первый случай не вызывает чтения данных из таблицы - только
индекс.

Posted via ActualForum NNTP Server 1.4

26 авг 08, 15:42    [6110534]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Dihotom
Member

Откуда:
Сообщений: 453
pkarklin
Dihotom
Т.е. Вы предлагаете перед каждым действием проверять его на безошибочную выполнимость даже в тех случаях, когда ошибка может возникнуть в 0.01% случаев?


Скажите мне, в чем принуципиальная разница в коде. Грубо:

INSERT
IF <ИС нарушения PK> UPDATE

и

UPDATE ...
IF @@rowcount = 0 INSERT ...

или скажем:

IF EXISTS()
  UPDATE
ELSE
  INSERT

Это не я предлагая - это Вы предлагаете везде писать обработчики ИС и уходить на другой оператор. Для меня - ошибка в любом из опертаторов транзакции - ее откат.

Dihotom
Кстати, у меня появился смежный вопрос: активные участники дискуссии, не могли бы Вы "представиться" - Вы администраторы БД или же разработчики-проектировщики? Начну, я - разработчик.


За 12 лет работы есть богатый опыт во всех областях.

Как же не Вы предлагали?
pkarklin
На Ваше "ветвление" я уже отвечал здесь: Нужна помощь Вместо тупой отправки инструкции можно выполнить проверку.

Т.е. в наборе потенциально нарушающих целостность операторов (но транзакция при этом может ветвиться) Вы каждый будете проверять даже в том случае, если ошибка маловероятна. В моем же случае альтернативные ветки будут работать только при возникновении конкретной ошибки. Кроме того, решение с исключениями структурирование - есть четкое разделение между действительно ошибочными ситуациями (исключение), которые будут в обработчике, и штатными ветвлениями транзакции.
26 авг 08, 15:52    [6110618]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 [7] 8 9 10 11 .. 25   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить