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

Откуда: Москва (Муром)
Сообщений: 74930
1.1 и 2.1 - 8, 4
1.2 и 2.2 - 8, выполнение будет прервано
27 авг 08, 15:10    [6115349]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Я понимаю, что Вас интересует.

Вариант:

BEGIN TRANSACTION;  -- 1
    INSERT ...      -- 2
    UPDATE ...      -- 3
    INSERT ...      -- 4
COMMIT TRANSACTION; -- 5
                    -- 6

В случие только генерации исключения в триггере, при SET XACT_ABORT OFF и до версии 2005 (только в ней появились try...catch) должен быть написан так:

BEGIN TRANSACTION; 
  INSERT ...      
  IF @@error <> 0 GOTO ErrHnd
  UPDATE ...      
  IF @@error <> 0 GOTO ErrHnd
  INSERT ...      
  IF @@error <> 0 GOTO ErrHnd
COMMIT TRANSACTION
RETURN
ErrHnd:
  ROLLBACK

Если мы хотим корректно отработать все ошибки и декларативные и ошибки "бизнес-логики".
27 авг 08, 15:23    [6115453]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Dihotom
Member

Откуда:
Сообщений: 453
pkarklin
Я понимаю, что Вас интересует.

Да, совершенно верно.
Таким образом, спор получился сильно завязанным на возможности СУБД, а следовательно, таким вот неконструктивным и порой эмоциональным.
Разработчик (№1) триггера под SQL Server просто не имеет морального права генерировать в нем исключение (а генерация исключения в триггере - это как раз то, на чем настаиваю я), потому что он становится зависим от добросовестности другого разработчика (№2), который пишет транзакцию. Потому что если разработчик №2 задал режим SET XACT_ABORT OFF и не создал блок обработки ошибок, то транзакция будет отрабатвать, как минимум, странно - в данном конкретном примере пропустит UPDATE, но выполнит последующий INSERT и COMMIT. Именно поэтому гарантированно проблем не будет только в том случае, если выполнить откат в триггере.
Всё встало на свои места.

Блин, всё-таки я люблю Oracle :))
27 авг 08, 15:36    [6115561]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
MasterZiv
Member

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

Dihotom wrote:

> Действие A, выполняющее некоторую модификацию данных.
> Действие B, выполняющее модификацию с проверкой целостности данных в
> триггере. Триггер обнаруживает нарушение целостности, за отсутствием
> исключений никак не может сообщить об этом непосредственно транзакции
> (*так ли это?*), поэтому просто откатывает её.
> Действие C, выполняющее некоторую модификацию данных (*в случае отката
> транзакции будет ли они выполнено, ведь триггер выполнил откат, но как
> об этом узнает "Действие C"?*)

Какой такой транзакции надо чего-то сообщять, я не понимаю.
Транзакция - это последовательно выполняющийся код.

BEGIN TRAN
ACTION_А
if @@error <> 0
begin
if transaction_active rollback transaction
goto end
end

ACTION_B
if @@error <> 0
begin
if transaction_active rollback transaction
goto end
end

ACTION_C
if @@error <> 0
begin
if transaction_active rollback transaction
goto end
end

end:
COMMIT

Вот примерно что-то такое.

Posted via ActualForum NNTP Server 1.4

27 авг 08, 15:45    [6115632]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Dihotom
Таким образом, спор получился сильно завязанным на возможности СУБД


Безусловно. Странно бы было вести дискуссию о подходах в разработке в абстрактных терминах.

Dihotom
Разработчик (№1) триггера под SQL Server просто не имеет морального права генерировать в нем исключение (а генерация исключения в триггере - это как раз то, на чем настаиваю я), потому что он становится зависим от добросовестности другого разработчика (№2), который пишет транзакцию. Потому что если разработчик №2 задал режим SET XACT_ABORT OFF и не создал блок обработки ошибок, то транзакция будет отрабатвать, как минимум, странно - в данном конкретном примере пропустит UPDATE, но выполнит последующий INSERT и COMMIT. Именно поэтому гарантированно проблем не будет только в том случае, если выполнить откат в триггере.


Как мне казалось, я уже много раз повторил, что моральное право одно, транзакция - единый неделимый блок. Именно поэтому, если мы пишем проверку целостности данных в триггере, то мы там и RAISERROR (дабы выдать, что за ощибка) и ROLLBACK. И чего бы там не написал разработчик 2 и в каком режиме - цель (атомарность действия транзакции) будет достигнута.

Вы же исходите из постулата, что принимать решение о том, что делать с транзакцией должне разработчик 2.
27 авг 08, 15:55    [6115722]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Dihotom
Member

Откуда:
Сообщений: 453
MasterZiv
Какой такой транзакции надо чего-то сообщять, я не понимаю.
Транзакция - это последовательно выполняющийся код.

Мы уже со всем разобрались - см. чуть выше :)
27 авг 08, 16:01    [6115772]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Dihotom
Member

Откуда:
Сообщений: 453
pkarklin
Как мне казалось, я уже много раз повторил, что моральное право одно, транзакция - единый неделимый блок. Именно поэтому, если мы пишем проверку целостности данных в триггере, то мы там и RAISERROR (дабы выдать, что за ощибка) и ROLLBACK. И чего бы там не написал разработчик 2 и в каком режиме - цель (атомарность действия транзакции) будет достигнута.

Вы же исходите из постулата, что принимать решение о том, что делать с транзакцией должне разработчик 2.

А вот это значит, что Вы так и не вняли моим доводам против этого подхода.
Мой постулат именно такой - решение за тем, кто начал транзакцию. Невыполнение одного оператора в транзакции никак не может свидетельствовать об однозначной неуспешности всей транзакции. Вы транзакцию представляете как линейную последовательность операторов, где такая логика допустима. А для меня транзакция - это сложный процесс переводящий БД из одного состояния в другое, в котором, например, невыполнение одного оператора может быть заменено выполнением другого.
Так вот SQL Server, получается, не обеспечивает независимость разработчика конкретного оператора и разработчика транзакции. И, тоже повторюсь, именно это является единственной причиной по которой там нужно делать откат в триггере.
В других СУБД (в первую очередь, я имею ввиду Oracle, конечно), такая независимость есть. Разработчик оператора понятия не имеет, как этот оператор будет использоваться и критично ли его выполнение для успешного завершения транзакции. Именно поэтому он генерирует исключение, которое перехватывает разработчик транзакции и принимает необходимые решения по обработке.
27 авг 08, 16:19    [6115919]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
pkarklin
Member

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


Можно реальный (а не придуманный) пример из Вашей практики, где Вы действовали таким способом? Если это будет кусок кода - вообще великолепно.
27 авг 08, 16:40    [6116117]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
И еще вопрос.

Dihotom
Именно поэтому он генерирует исключение, которое перехватывает разработчик транзакции и принимает необходимые решения по обработке.


Что произойдет, если разработчик транзакци не перехватит и не обработает?
27 авг 08, 16:41    [6116127]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Повторюсь в не знаю какой раз:

Dihotom
Разработчик оператора понятия не имеет, как этот оператор будет использоваться и критично ли его выполнение для успешного завершения транзакции.


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

ЗЫ. Кмк, я повторяю прописные истины.
27 авг 08, 16:44    [6116145]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
hvlad
Member

Откуда:
Сообщений: 11551
pkarklin
Как мне казалось, я уже много раз повторил, что моральное право одно, транзакция - единый неделимый блок. Именно поэтому, если мы пишем проверку целостности данных в триггере, то мы там и RAISERROR (дабы выдать, что за ощибка) и ROLLBACK. И чего бы там не написал разработчик 2 и в каком режиме - цель (атомарность действия транзакции) будет достигнута.
Триггер не имеет достаточного объёма информации о данной тр-ции.
И целостность БД (логическую, есс-но) в рез-те действий тр-ции определяет именно разработчик 2, т.к. именно он её создал.

pkarklin
Вы же исходите из постулата, что принимать решение о том, что делать с транзакцией должне разработчик 2.
И это правильно
27 авг 08, 17:13    [6116398]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
hvlad
Member

Откуда:
Сообщений: 11551
pkarklin
И еще вопрос.

Dihotom
Именно поэтому он генерирует исключение, которое перехватывает разработчик транзакции и принимает необходимые решения по обработке.


Что произойдет, если разработчик транзакци не перехватит и не обработает?
Он будет уволен.
27 авг 08, 17:13    [6116403]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
hvlad
Триггер не имеет достаточного объёма информации о данной тр-ции.


В который раз тут всплывает эта фраза. Что это за сокровенная информация такая? Транзакия она или есть или ее нет. Т.е. или все или ничего.

hvlad
И целостность БД (логическую, есс-но) в рез-те действий тр-ции определяет именно разработчик 2, т.к. именно он её создал.


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

Помоему именно в понимании "транзакции" мы с Вами и расходимся.

hvlad
Он будет уволен.


Меня не организационные вопросы интересуют, а технические. Что будет с базой, в каком состоянии останется текущая сессия, транзакция? Что в ней можно\нельзя будет сделать.
27 авг 08, 17:35    [6116536]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Dihotom
Member

Откуда:
Сообщений: 453
pkarklin
Можно реальный (а не придуманный) пример из Вашей практики, где Вы действовали таким способом? Если это будет кусок кода - вообще великолепно.

Можно, но всё же без кода.
В системе производится регистрация урегулированных округленных балансов банков (101-е формы).
В таблицу REPORT помещаются данные непосредственно о самих отчетах.
В таблицу REPORT_ROW помещаются урегулированных округленные данные по балансовым счетам, входящим в отчет (пусть нас интересует только активный исходящий остаток - колонка ACT_OUT_REST).
В таблицу REPORT_ITOG помещаются арифметически округленные округленные итоги отчета (пусть нас интересует только активный исходящий остаток - колонка ACT_OUT_REST).
Бизнес-требование: арифметически округленные округленные итоги отчета должны быть равны сумме округленных данных по всем балансовым счетам отчета.
Функциональное требование: в случае нарушения бизнес-требования пользователь имеет возможность отменить регистрацию отчета или выполнить корректировку итогов путем автоматического вычисления суммы балансовых счетов.
Статистика: некорректные отчеты (не удовлетворяющие бизнес-требованию) составляют неболее 0.1% от общего числа отчетов.

Реализация: в транзакции заносим запись об отчете в REPORT, записи по балансовым счетам в REPORT_ROW, записи по итогам в REPORT_ITOG. На REPORT_ITOG навешиваем триггер, проверяющий логическую целостность данных - сходимость итогов с суммой балансовых счетов. Если целостность нарушается - генерируем исключение. Таким образом, оператор регистрации итогов не выполнился. Перехватываем исключение и в рамках этой же транзакции анализируем настройки пользователя (переданные транзакции в виде параметров ХП). Если пользователь требует выполнить корректировку, то корректируем итоги и повторно осуществляем их регистрацию. В противном случае - откатываемся.

pkarklin
Что произойдет, если разработчик транзакци не перехватит и не обработает?

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

pkarklin
Повторюсь в не знаю какой раз:

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

ЗЫ. Кмк, я повторяю прописные истины.

Если Вы называете эти истины прописными, то скажите мне, где и кем они прописаны. Я где-то читал о разнице в подходах к транзакциям у разработчиков на разных СУБД. Что значит, "этому оператору нечего делать в этой транзакции"? Ему там самое место. Логика транзакции допускает его невыполнение, но этот оператор часть этой логики. Зачем что-то хитрое придумывать, чтобы его оттуда выкинуть?
27 авг 08, 17:44    [6116586]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Dihotom
Member

Откуда:
Сообщений: 453
pkarklin
Тогда к чему вообще этот триггер?! Ведь его задача внести такие ограничения, чтобы именно триггер, а не тот, кто будет манипулировать иструкциями определял, что делать с транзакцией.

Можно ведь и с другого бока зайти.
Возьмем ограничение "первичный ключ". Что делает SQL Server, когда нарушается это ограничение? Неужели он берет и прям откатывает всю транзакцию?
Я в этом сильно сомневаюсь. Наверняка он генерит ошибку (исключение ли, глобальную переменную ли заполняет) и дальнейшее поведение сваливает на плечи программиста.

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

P.S.: Если Вы мне сейчас скажете, что SQL Server при нарушении декларативного ограничения сразу же откатывает транзакцию, то... ну не знаю, я буду в шоке.
27 авг 08, 17:53    [6116638]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
MasterZiv
Member

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

Dihotom wrote:
> В других СУБД (в первую очередь, я имею ввиду Oracle, конечно), такая
> независимость есть. Разработчик оператора понятия не имеет, как этот
> оператор будет использоваться и критично ли его выполнение для успешного
> завершения транзакции. Именно поэтому он генерирует исключение, которое
> перехватывает разработчик транзакции и принимает необходимые решения по
> обработке.

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

Posted via ActualForum NNTP Server 1.4

27 авг 08, 17:53    [6116644]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Dihotom
Если Вы называете эти истины прописными, то скажите мне, где и кем они прописаны. Я где-то читал о разнице в подходах к транзакциям у разработчиков на разных СУБД.


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

Dihotom
В этом случае исключение дойдет до клиента. Транзакция откатиться.


Вот здесь попрошу уточнить. Кто ее откатит? Обработчик на клиенте? Если нет там такого обработчика с откатом?

Dihotom
Что значит, "этому оператору нечего делать в этой транзакции"? Ему там самое место. Логика транзакции допускает его невыполнение, но этот оператор часть этой логики. Зачем что-то хитрое придумывать, чтобы его оттуда выкинуть?


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

По поводу примера. Спасибо! Возьму паузу на его разбор. Отвечу, возможно, уже завтра.
27 авг 08, 17:57    [6116663]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
pkarklin
Member

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

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

P.S.: Если Вы мне сейчас скажете, что SQL Server при нарушении декларативного ограничения сразу же откатывает транзакцию, то... ну не знаю, я буду в шоке.


Шока не будет. :) Естественно, при дефолтной установке SET XACT_ABORT OFF не будут выполнены инструкции, нарушающие ограничения.

Вот только все системы, который проходили через мои руки, работали только при SET XACT_ABORT ON. И там, где были триггера (с проверкой), в них был ROLLBACK.
27 авг 08, 18:03    [6116691]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
MasterZiv
Member

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

Dihotom wrote:

> Возьмем ограничение "первичный ключ". Что делает SQL Server, когда
> нарушается это ограничение? Неужели он берет и прям откатывает всю
> транзакцию?

Выполнение стейтмента, изменяющего эту таблицу, прерывается
и откатывается.
Формируется код ошибки в переменной @@error. В современных
версиях также формируется соответствующее исключение.

Код, отвечающий за выполнение многооператорной транзакции,
обязан проверить код ошибки или поймать исключение и что-то
сделать со всей транзакцией (откатить или возможно нет).

> Я в этом сильно сомневаюсь. Наверняка он генерит ошибку (исключение ли,
> глобальную переменную ли заполняет) и дальнейшее поведение сваливает на
> плечи программиста.

Да, так и есть.

> P.S.: Если Вы мне сейчас скажете, что SQL Server при нарушении
> декларативного ограничения сразу же откатывает транзакцию, то... ну не
> знаю, я буду в шоке.

Откатывает, но не всю.

Posted via ActualForum NNTP Server 1.4

27 авг 08, 18:09    [6116714]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
MasterZiv
Member

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

pkarklin wrote:

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

Кстати нет. В стандарте, насколько я знаю, определена flat transaction
model, которая на деле вообще неприменима. Всё, что больше этой модели -
как бы расширения конкретной СУБД. И вложенные, и автономные транзакции,
и параллельные, и savepoints - всё это во всех СУБД разное.

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

И это кстати тоже не факт. В смысле, есть такие модели транзакций,
когда даже такое допускается. Они не ACID, они другие, но есть.
Напр. автономные транзакции, которые есть кажется в оракле.

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

Posted via ActualForum NNTP Server 1.4

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

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

Считать можно как угодно. И я уж согласился с тем, что если в СУБД нет возможности делать что-то хорошо (и правильно), то не нужно лишний раз тыкать пальцем в разработчиков "вы не правы".
Сейчас речь идет уже о том, что если есть возможность делать хорошо (и правильно), то нужно делать именно так, а не прикрываться принципом "сколько людей, столько и мнений".

pkarklin
Гм... Всю жизнь считал, что уж к определению транзкций, подход у всех должен быть одинаков.

Уверен, что к определнию подход у всех один, а вот к интерпретации... :) На сколько я знаю, во многих СУБД транзакции до сих пор считаются слишком затрантными, что накладывает на разработчиков неформальное восприятие транзакции как чего-то очень короткого. Вроде бы даже в SQL Server'е эта проблема была до недавнего времени. В общем, СУБД невольно формирует у разработчика свою интерпретацию определения транзакции.

pkarklin
Вот здесь попрошу уточнить. Кто ее откатит? Обработчик на клиенте? Если нет там такого обработчика с откатом?

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

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

Но это же не частичное выполнение, а вполне законченное. Просто оно нелинейное.
27 авг 08, 18:15    [6116736]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
MasterZiv

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


Я об этом уже упоминал. Нужна помощь
27 авг 08, 18:17    [6116742]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Dihotom
Member

Откуда:
Сообщений: 453
pkarklin
Вот только все системы, который проходили через мои руки, работали только при SET XACT_ABORT ON. И там, где были триггера (с проверкой), в них был ROLLBACK.

А я уже объяснил свою версию, почему в триггерах используется ROLLBACK (в SQL Server) - потому что это единственный гарантированный способ избежать проблем от наличия корявых разработчиков транзакций.

Всё, я домой. До завтра :)
27 авг 08, 18:19    [6116754]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Bogdanov Andrey
Member

Откуда: Да уже и сам не знаю...
Сообщений: 2203
MasterZiv
> Возьмем ограничение "первичный ключ". Что делает SQL Server, когда
> нарушается это ограничение? Неужели он берет и прям откатывает всю
> транзакцию?

Выполнение стейтмента, изменяющего эту таблицу, прерывается
и откатывается.
Формируется код ошибки в переменной @@error. В современных
версиях также формируется соответствующее исключение.

Код, отвечающий за выполнение многооператорной транзакции,
обязан проверить код ошибки или поймать исключение и что-то
сделать со всей транзакцией (откатить или возможно нет).
То есть для декларативных ограничений SQL Server таки применяет ту концепцию, которую "ораклисты" защищают. А вот для триггерных почему-то нет.
Современные методики предполагают, что способ реализации инкапсулирован (собственно, упоминавшийся выше принцип "изолированности слоев" и есть инкапсуляция) внутри объекта с тем, чтобы код приложения, использующего объект, не зависил от реализации.
А тут получается, что приложение должно знать о том, как именно реализовано ограничение.
27 авг 08, 21:13    [6117254]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
hvlad
Member

Откуда:
Сообщений: 11551
pkarklin
hvlad
Триггер не имеет достаточного объёма информации о данной тр-ции.


В который раз тут всплывает эта фраза. Что это за сокровенная информация такая? Транзакия она или есть или ее нет. Т.е. или все или ничего.
Контекст вызова. Окружение. Триггер понятия не имеет о намерениях того, кто сделал insert. Его дело маленькое - не пущать отрицательные остатки, например. И всё. Остальное - вне его компетенции.

Простой пример привёл Dihotom.

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

pkarklin
hvlad
И целостность БД (логическую, есс-но) в рез-те действий тр-ции определяет именно разработчик 2, т.к. именно он её создал.


Тогда к чему вообще этот триггер?! Ведь его задача внести такие ограничения, чтобы именно триггер, а не тот, кто будет манипулировать иструкциями определял, что делать с транзакцией.
С данными, а не с тр-цией. Триггер поддерживает лог.целостность данных в БД. Не более, и не менее.

pkarklin
Помоему именно в понимании "транзакции" мы с Вами и расходимся.
Возможно

pkarklin
hvlad
Он будет уволен.
Меня не организационные вопросы интересуют, а технические. Что будет с базой, в каком состоянии останется текущая сессия, транзакция? Что в ней можно\нельзя будет сделать.
В худшем случае в сессии останется висеть не закоммиченная тр-ция.
Типичная ошибка программиста, это что-то новое ?
27 авг 08, 21:20    [6117266]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 6 7 8 9 10 [11] 12 13 14 15 .. 25   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить