Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 16 17 18 19 20 21 22 23 24 [25]
 Re: Нужна помощь  [new]
Gluk (Kazan)
Member

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

Или в Оракле как-то по-другому?


Ага :)
В Oracle по умолчанию READ COMMITTED
SERIALIZABLE нужно выставлять явно (и на то есть причины)
29 май 09, 16:29    [7245594]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
dbdev___
Guest
Коллеги!

Я прочитал только 10 страниц этого жуткого холивара, в которых идет речь о том, правильно ли откатывать всю транзакцию в триггере или неверно.

В итоге обсуждения (ну не в самом итоге, но странице на 8й:) ), аргументация уважаемого pkarklin свелась к тому, что он не допускает ветвления выполнения кода транзакции в зависимости от выброшенных исключений. То есть, транзакция должна представлять из себя:
BEGIN
INSERT
IF (явная проверка целостности)
  UPDATE
ELSE
  INSERT
COMMIT

а не

BEGIN
INSERT
если выброшено исключение
INSERT
если не выброшено
UPDATE
COMMIT

Я несколько страниц недоумевал, чем же так не угодила pkarklin обработка исключений. И тут меня осенило! В MSSQL Server же не такого понятия как TRY-CATCH или BEGIN-EXCEPTION-END. Это же все объясняет! Нецелесообразно каждый раз проверять IF @@ERROR, ведь действительно проще проверить целостность явно.

Прошу прощения, не стал дочитывать и решил запостить это.
15 июн 09, 23:24    [7302751]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
dbdev___
И тут меня осенило! В MSSQL Server же не такого понятия как TRY-CATCH или BEGIN-EXCEPTION-END. Это же все объясняет! Нецелесообразно каждый раз проверять IF @@ERROR, ведь действительно проще проверить целостность явно.

Бред, если честно.
как в части try-catch, так и в частях IF @@ERROR и явных проверок.
И, как следствие - бредовый выводу.

Извини, если что.
16 июн 09, 00:18    [7302848]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
dbdev___
Guest
locky,

Сорри, плохо изложил, до 2005-го MSSQL TRY-CATCH в T-SQL не было как такового. Была проверка IF @error и все.

Я так понимаю, что многие T-SQL программисты работали с SQL Server начиная с 7/2000, и некоторые привычки остались еще со времен старых версий, такие например, как явная проверка целостности (не вставить случайно существующее значение туда где PK/UK). Ну не будешь же if @error после каждой вставки проверять? Я вот что подразумевал.

Ладно, брежу уже ночью...
16 июн 09, 02:04    [7303027]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
dbdev___
locky,

Сорри, плохо изложил, до 2005-го MSSQL TRY-CATCH в T-SQL не было как такового. Была проверка IF @error и все.

Я так понимаю, что многие T-SQL программисты работали с SQL Server начиная с 7/2000, и некоторые привычки остались еще со времен старых версий, такие например, как явная проверка целостности (не вставить случайно существующее значение туда где PK/UK). Ну не будешь же if @error после каждой вставки проверять? Я вот что подразумевал.

Ладно, брежу уже ночью...

Выделенное болдом - бред.
Причем туту "явная проверка целостности" к проверке @@error после каждого стейтмента? второе включает, но не ограничивается первым.
16 июн 09, 09:05    [7303272]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
pkarklin
Member

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

dbdev___
Я так понимаю, что многие T-SQL программисты работали с SQL Server начиная с 7/2000,


Вы не поверите, что некоторые из многих "застали" еще 6.5, и, даже, 4.2.

dbdev___
не допускает ветвления выполнения кода транзакции в зависимости от выброшенных исключений.


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

dbdev___
И тут меня осенило!


И тут Остапа понесло... ((с) Ильф и Петров, 12 стульев)

dbdev___
как явная проверка целостности (не вставить случайно существующее значение туда где PK/UK).


Давайте так...Декларативные ограничения ни в жисть не дадут их нарушить, хотим мы этого или нет. Можно, конечно, придумать сценарий, когда отлов такой ИС м.б. обработан внутри транзакции. НО... Раз мы знаем, как обработать, ТО, значит, мы знаем, КАК должны развиваться события, не приводя к ИС. Поэтому грубо <явная проверка> = <обработка исключительной ситуации>. Если Вам так будет угодно.


dbdev___
Ну не будешь же if @error после каждой вставки проверять?


Кмк, существует два возможных варианта:

1. Монопенисуальная обработка любой ИС - читай откат транзакции;
2. Индивидуальная обработка ИС после каждой инструкции.

Не так ли?
16 июн 09, 13:54    [7305024]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
dbdev___
Guest
pkarklin
Отложил удочки в сторону...

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

dbdev___

как явная проверка целостности (не вставить случайно существующее значение туда где PK/UK).


Давайте так...Декларативные ограничения ни в жисть не дадут их нарушить, хотим мы этого или нет. Можно, конечно, придумать сценарий, когда отлов такой ИС м.б. обработан внутри транзакции. НО... Раз мы знаем, как обработать, ТО, значит, мы знаем, КАК должны развиваться события, не приводя к ИС. Поэтому грубо <явная проверка> = <обработка исключительной ситуации>. Если Вам так будет угодно.


Да я же с этим не спорю. Мне просто почему-то кажется, что именно отсутствие TRY-CATCH в старых версиях mssql диктует этот стиль программирования. Согласны со мной? Работая с теми же pg или oracle у меня рука не поднимается делать лишний запрос. Зачем? Лучше отловить конкретное исключение, и работать быстрее будет (один запрос вместо двух), и нагляднее (про нагляднее - это имхо).

pkarklin

dbdev___
Ну не будешь же if @error после каждой вставки проверять?


Кмк, существует два возможных варианта:

1. Монопенисуальная обработка любой ИС - читай откат транзакции;
2. Индивидуальная обработка ИС после каждой инструкции.

Не так ли?


Ага, все именно так. И возвращаясь к теме Rollback'а в триггере, не обрубаете ли вы напрочь вариант №2 с таким подходом?
16 июн 09, 14:40    [7305362]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
softwarer
Member

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

(пожав плечами) Мне что-то вспомнились программы, считающие исключение необходимым и достаточным условием для того, чтобы упасть.

pkarklin
Раз мы знаем, как обработать, ТО, значит, мы знаем, КАК должны развиваться события, не приводя к ИС. Поэтому грубо <явная проверка> = <обработка исключительной ситуации>.

Нет. Совершенно не так.

Допустим, у нас есть обычная учётная система, снабжённая доп. фенечкой: при некоторых операциях (скажем, когда товар готовится к отгрузке) пишется емейл клиенту. Допустим, база даёт ошибку на попытку сделать insert в таблицу отправленных емейлов. Почему - ну, например, кончилась дисковая квота для этой таблицы. Или сбой диска в очередном её блоке. Или ещё что-нибудь "объективно-неожиданное".

Что мы имеем в итоге. Как Вы "явно проверите" такие ситуации - хотел бы я посмотреть. По Вашему предложению транзакция откатывается, как и все следующие подобные. Работа фирмы просто встаёт. Тем временем клиент, получивший емейл, приезжает за товаром и получает фигу. И всё из-за мелочи, которую вполне можно было бы просто игнорировать с сообщением администратору "разберись на досуге".

dbdev___
Ну не будешь же if @error после каждой вставки проверять?

Без исключений - другого варианта просто нет.

pkarklin
Кмк, существует два возможных варианта:

1. Монопенисуальная обработка любой ИС - читай откат транзакции;
2. Индивидуальная обработка ИС после каждой инструкции.

Подход "чёрное или белое".

pkarklin
Не так ли?

(глядя на окружающий мир) Да-да, конечно, два цвета.
16 июн 09, 14:54    [7305451]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
dbdev___
Да я же с этим не спорю. Мне просто почему-то кажется, что именно отсутствие TRY-CATCH в старых версиях mssql диктует этот стиль программирования. Согласны со мной? Работая с теми же pg или oracle у меня рука не поднимается делать лишний запрос. Зачем? Лучше отловить конкретное исключение, и работать быстрее будет (один запрос вместо двух), и нагляднее (про нагляднее - это имхо).


Еще раз. "Лишний запрос" я буду делать только в том случае, если мне по условиям бизнес-логики необходимо выполнить ту или иную проверку и выдать пользователю вразумительное сообщение об ошибке, вместо Unique Constraint Violation. Во всех остальных случаях я тупо откачу транзакцию в случае нарушение какого-либо ограничения, пусть, декларативного, пусть в следствии ROLLBACK в триггере.

dbdev___
И возвращаясь к теме Rollback'а в триггере, не обрубаете ли вы напрочь вариант №2 с таким подходом?


Вариант № 2 предполагает использование разработчиком, который использует логику (ROLLBACK в триггере), созданную проектировщиком бд. Поэтому, как решил проектировщик (Померла, значит померла ((с) Вий, Гоголь), значит так тому и быть. И чтобы Вы не сказали на более верхнем уровне, уровень целостности бд раставит все точки над Й. По-моему, я это уже в 958 раз повторяю...
16 июн 09, 15:21    [7305618]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
hvlad
Member

Откуда:
Сообщений: 11628
pkarklin
существует два возможных варианта:

1. Монопенисуальная обработка любой ИС - читай откат транзакции;
2. Индивидуальная обработка ИС после каждой инструкции.

Не так ли?
Не так. Есть ещё структурная обработка исключений. Не в basic'ах
16 июн 09, 16:10    [7305919]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Senya_L
Member

Откуда: Москва
Сообщений: 5381
pkarklin
По-моему, я это уже в 958 раз повторяю...
Вы можете повторить это еще столько же раз, но всегда найдется когорта сомневающихся, которая будет талдычить о частичном подтверждении результатов транзакции и суперсложной бизнес-логике.
16 июн 09, 17:17    [7306454]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
Senya_L
pkarklin
По-моему, я это уже в 958 раз повторяю...
Вы можете повторить это еще столько же раз, но всегда найдется когорта сомневающихся, которая будет талдычить о частичном подтверждении результатов транзакции и суперсложной бизнес-логике.

Собственно, они будут не настолько неправы.
Потому как случаи - бывают разные.
16 июн 09, 17:32    [7306585]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Senya_L
Member

Откуда: Москва
Сообщений: 5381
locky
Senya_L
pkarklin
По-моему, я это уже в 958 раз повторяю...
Вы можете повторить это еще столько же раз, но всегда найдется когорта сомневающихся, которая будет талдычить о частичном подтверждении результатов транзакции и суперсложной бизнес-логике.

Собственно, они будут не настолько неправы.
Потому как случаи - бывают разные.
Бывают. Но с каждым надо предметно разбираться, а не устраивать войны "чиста из принципа".
16 июн 09, 20:05    [7307205]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
Senya_L
Бывают. Но с каждым надо предметно разбираться, а не устраивать войны "чиста из принципа".

Боюсь что значительная часть разработчиков возводят "исключительные ситуации" в ранг "так надо всегда".
16 июн 09, 20:42    [7307265]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 16 17 18 19 20 21 22 23 24 [25]
Все форумы / Сравнение СУБД Ответить