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

Откуда: SPb
Сообщений: 5488
Dimitry Sibiryakov

MasterZiv
Вот они всем свою религию и несут.

Да нет, не мы религию несём. Это на нас идёт поток людей вроде
топикстартера, у которых мозг заточен на "специфичные фичи" MS SQL.
Не поделитесь опытом как Вам удалось избежать заточки мозгов на "специфичные фичи" IB? ;)

hvlad
Что я придумал ? Что роллбэк в триггере, а не в точке старта тр-ции нарушает изолированность слоёв ПО ?
А почему роллбэк в триггере нарушает изолированность слоёв ПО, а исключение на сервере, которое надо обработать на клиенте - не нарушает?
26 авг 08, 00:19    [6107690]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
hamjak
Member

Откуда:
Сообщений: 11
Dimitry Sibiryakov

MasterZiv
Вот они всем свою религию и несут.

Да нет, не мы религию несём. Это на нас идёт поток людей вроде
топикстартера, у которых мозг заточен на "специфичные фичи" MS SQL.

В-общем, я даже рад, что топикстартер остановился на MySQL... Нашим легче...

Специфичные фичи??? Если эти фичи официально поддерживаются, то почему бы ими не пользоваться???
Не бери это в плюс МуСКЛ, Просто мне надо удалить МС СКЛ Серв,
Про вашу изоляцию слоев, А не есть ли это изоляция, когда вся логика реализуется на уровне серва??? Зачем клиенту обрабатывать исключения и пытаться комиттить транзакцию??? Вот это на мой взгляд извращенство (за исключением некоторых случаев,,, с которыми мне сталкиваться не приходилось), Обычный пользователь ничего, практически ничего, не будет знать об ограничениях в БД, Использование триггера для отката транзакции в рамках текущего подключения к БД выглядит вполне логично,
Сорри,,, отойду от темы,,, можете не отвечать, не обижусь,
Поставил федоракор линукс 9,
Мало того что при выборе пакетов при установке инсталятор вылетал с ошибкой, так еще и прибавился глюк с клавой после установки, На англ/рус язык можно переключиться только методом: 2 шифта, а затем клаву от компа отсоеденить и присоеденить, тогда все норм, И на клаве символы не попадают,,, точку до сих пор не откопал)))(по тексту я думаю понятно))) Кто встречался с этим??? Хелп плиз!
keyboard - genius slimstar pro (USB)
26 авг 08, 00:32    [6107717]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
hvlad
Member

Откуда:
Сообщений: 11551
SergSuper
hvlad
Что я придумал ? Что роллбэк в триггере, а не в точке старта тр-ции нарушает изолированность слоёв ПО ?
А почему роллбэк в триггере нарушает изолированность слоёв ПО, а исключение на сервере, которое надо обработать на клиенте - не нарушает?
Потому что тр-цию не триггер начинал. И не ему делать вывод об её окончании.

И - кто сказал, что исключение обязано быть обработанным только клиентом ? Оно должно быть обработано в соответствующем слое или ниже.

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

А вот с принудительным роллбеком тр-ции - никто не может ничего в ней сделать, кроме попытки повтора операции в другой тр-ции.
26 авг 08, 00:49    [6107742]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
hvlad
Потому что тр-цию не триггер начинал. И не ему делать вывод об её окончании.


В Вашем высказывании подспудно прослеживается мысль: "Кто начал транзакцию - тот ее и должен закончить". Я не прав?

Объясните, почему сервер, в случие определенных ошибок может принять решение об откате транзакции? Не он же ее начинал? Это его дело?

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

Каким основопологающим принципам (и где они записаны) противоречит такой подход? Только тем, что некоторые СУБД не позволяют этого сделать?

hvlad
А вот с принудительным роллбеком тр-ции - никто не может ничего в ней сделать, кроме попытки повтора операции в другой тр-ции.


И правильно, ибо разработчик бд принял такое решение и откатил транзакцию в триггере. Заметьте, что "целостность" данных не нарушена. Зачем еще изобретать какие-то обработчики ИС на каких-то промежуточных звеньях, если серверная сторона полностью контролирует все эти исключительные ситуации и их обработку?
26 авг 08, 08:14    [6107922]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
DBA-шник
Guest
Ну наваяли, блин. Копьев поломать, клиент, сервер.
Серверу вообще мало известно о клиентах. У него есть сессии. И состояния пула вызовов, отложенных фиксаций, открытых наборов (курсоров), которое , бывает, кардинально меняется при фиксациях и откатах транзакций. Картина обобщена для всего, что именует себя сервером. Теперь из классической теории множеств: меньшее не может включать в себя большее. Это факт. Триггер, который является мелкой единицей не может являться точкой ветвления для всей системы, т.е. триггер (имеется в виду табличный) видит изменения только в своей таблице, в то же время транзакции придуманы для управления изменениями в множестве таблиц. Таким образом, управления транзакциями в триггерах имеет статус оператора GOTO в процедурных языках (кто еще помнит что это такое).
Камень в сторону мелкомягких. Из ПРОДОЛЖИТЕЛЬНОГО опыта заявляю: мелкомягкие допускают много вольностей в написании ПО, что приводит к БЫСТРОЙ РАЗРАБОТКЕ и заниженому уровню АДЕКВАТНОСТИ РАЗРАБОТЧИКА готового приступить к работе. Но после продолжительной эксплуатации, эти вольности, приводят к НЕДОСТОВЕРНОСТИ БИЗНЕС-ДАННЫХ. Простой закон сохранения.
26 авг 08, 08:22    [6107929]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
pkarklin
Member

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


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

DBA-шник
т.е. триггер (имеется в виду табличный) видит изменения только в своей таблице


Да шо Вы говорите?!

SET XACT_ABORT ON
GO
USE tempdb
GO

CREATE TABLE T1(col1 int)
GO
CREATE TABLE T2(col1 int)
GO
CREATE TRIGGER T2_it ON T2 
FOR INSERT AS
SET NOCOUNT ON
DECLARE @RowCount int
SELECT @Rowcount = COUNT(*) FROM T1
PRINT 'RowCount In T2 = ' + CAST(@RowCount AS varchar)
GO
BEGIN TRAN
INSERT T1(col1) VALUES(1)
INSERT T2(col1) VALUES(-1)
COMMIT
GO
DROP TABLE T1, T2

RowCount In T2 = 1

DBA-шник
Камень в сторону мелкомягких. Из ПРОДОЛЖИТЕЛЬНОГО опыта заявляю: мелкомягкие допускают много вольностей в написании ПО, что приводит к БЫСТРОЙ РАЗРАБОТКЕ и заниженому уровню АДЕКВАТНОСТИ РАЗРАБОТЧИКА готового приступить к работе. Но после продолжительной эксплуатации, эти вольности, приводят к НЕДОСТОВЕРНОСТИ БИЗНЕС-ДАННЫХ. Простой закон сохранения.


Всегда считал, что к НЕДОСТОВЕРНОСТИ БИЗНЕС-ДАННЫХ приводит кривизна рук разработчика, использующего инструмент, а не сам инструмент.
26 авг 08, 08:46    [6107958]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
"RowCount In T2" читать как "RowCount In T1"
26 авг 08, 08:48    [6107960]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
DBA-шник
Guest
Уважаемый
pkarklin

Множества - это основа для рассуждения. Моделирование окружающего мира (в наше время этим занимаются Математики) были и до компьютеров и будут после оных. Так что для выражения мыслей я пользуюсь терминами понятными в данном контексте образованному человеку.
Проблема GOTO в ПЯП это классика. Это как употребить "Жду падения яблока".
Извиняюсь о неверном употреблении термина. "Видит", употребляется в смысле "Реагирует", т.е. упор на сущность триггера, нежели на частнореализованные возможности единицы БД производства и маркетинга определенной фирмы.

По поводу мелкомягких. MS так сказать, убрала латинский язык из науки. Т.е. раньше, человек, чтобы что-то утверждать, должен был доказать способности своего ума - изучить латынь. Сейчас этого не требуется ,- посчитали это препятствием для юных дарований (самородков, так сказать). К чему привело - сами видите. Марксисты и торсионники, думаю, яркий пример.

Я всегда считал, что у пешеходного моста через пропасть должны быть перила. И если их нет, то сажать надо строителя, который такой мост возвел, а не орать "Нехрен пешеходам хромыми быть".
26 авг 08, 09:07    [6108013]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Уважаемый DBA-шник!

Вы, безусловно, сильны в аллегориях... ;)
26 авг 08, 09:24    [6108071]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
DBA-шник
Guest
pkarklin

Уважаемый DBA-шник!
Вы, безусловно, сильны в аллегориях... ;)

Спасибо.

Управление транзакциями из табличных триггеров - моветон.

Бездельник, картежник и недоучка, который, с помощью своей мамочки, облапошил уважаемую фирму, буквально - украл и нажился, сейчас занимается тем, что покупает и продает. Эта фирма - просто бренд в красивой упаковке, аналогично "Продукты НЕО". Не более. У этого выскочки еще хватило тупости написать (или заказать-купить-опубликовать) книгу под крикливым названием, при внимательном прочтении которой видится вся убогость интеллекта автора, даже в том случае, если он просто одобрил этот текст.
Как ни печально, превращение науки в бизнес прекратить нельзя.
Если Вы не понимаете к чему ведет кибернетику этот синий бренд, взгляните на медицину, в частности - фармацевтику. То, во что она превратилась в сегодняшние дни.
26 авг 08, 09:46    [6108147]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
MasterZiv
Member

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

hvlad wrote:

>
> Которую вы тут же и придумали. Вот если бы это было нарушение стандарта,
> или ещё чего-то специфицированного, тогда был бы разговор.
> А так - это просто ваши личные измышления. Мои могут быть другими.
> Ещё кого-то - третьими.
>
> Что я придумал ? Что роллбэк в триггере, а не в точке старта тр-ции
> нарушает изолированность слоёв ПО ?

Вы придумали это :

Хорошо спроектированный софт всегда разбит на слои, максимально изолированные
друг от друга. Откат тр-ции не в том слое, который её создавал, есть грубейшее
нарушение этой изоляции.

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

Posted via ActualForum NNTP Server 1.4

26 авг 08, 10:00    [6108190]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Bogdanov Andrey
Member

Откуда: Да уже и сам не знаю...
Сообщений: 2203
pkarklin
Объясните, почему сервер, в случие определенных ошибок может принять решение об откате транзакции? Не он же ее начинал? Это его дело?
Ну вот видите - вы ничего не поняли. По принципу изолированности слоев сервер не никогда не должен откатывать транзакцию, если он ее не начинал. Вы этот принцип можете не понимать и не принимать, для меня его ценность (так же как и инкапсуляции) очевидна. Его использование сильно повышает эффективность сопровождения и доработки ПО.

pkarklin
И правильно, ибо разработчик бд принял такое решение и откатил транзакцию в триггере.
Разработчик бд никакого представления отом, что в этой транзакции происходило, то есть он принял решение об откате сам не знает чего.
26 авг 08, 10:03    [6108207]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
MasterZiv
Member

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

hvlad wrote:

> Потому что тр-цию не триггер начинал. И не ему делать вывод об её
> окончании.

А кто начинал-то ? Я же уже писал, что если так рассуждать, то и
НАДО откатывать транзакцию в триггере.

> Т.е. если /некий слой/ стартовал тр-цию и запустил в ней запрос с
> процедурой, которая делает инсерт, который вызывает триггер, который
> вызывает другую процедуру, которая ... который вызывает исключение, то
> это исключение _может_ быть обработано в любой из этих
> процедур\триггеров или в /нашем слое/. Этим слоем может быть как
> GUI-клиент, так и апп-сервер, так и процедура на SQL сервере.

А почему не триггер ? Если в ЛЮБОМ слое, то самый последний триггер -
всего лишь низший из этих слоёв. Частный случай хранимой процедуры.

Posted via ActualForum NNTP Server 1.4

26 авг 08, 10:06    [6108212]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Bogdanov Andrey
Member

Откуда: Да уже и сам не знаю...
Сообщений: 2203
pkarklin
Всегда считал, что к НЕДОСТОВЕРНОСТИ БИЗНЕС-ДАННЫХ приводит кривизна рук разработчика, использующего инструмент, а не сам инструмент.
Это несмоненно, но использование некоторых принципов позволяет снизить влияние кривзны рук на достоверность данных, а уж совсем кривые руки не допустить к процессу вообще.
Если же стоит задача как можно быстрее и дешевле сваять что-то (и сплавить это заказчику - пусть потом сам с проблемами достоверности разбирается), то тут как раз принципы могут помешать.
Ну а прямыми руками и на плохом инструменте можно хорошо сыграть.
26 авг 08, 10:09    [6108225]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Bogdanov Andrey
Ну вот видите - вы ничего не поняли. По принципу изолированности слоев сервер не никогда не должен откатывать транзакцию, если он ее не начинал. Вы этот принцип можете не понимать и не принимать, для меня его ценность (так же как и инкапсуляции) очевидна. Его использование сильно повышает эффективность сопровождения и доработки ПО.


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

Bogdanov Andrey
Разработчик бд никакого представления отом, что в этой транзакции происходило, то есть он принял решение об откате сам не знает чего.


Здрастье - приехали. Он принял решение об откате того, что привело бы к нарушению целостности данных. Это для Вас не является аргументом для отката транзакции?
26 авг 08, 10:13    [6108236]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
MasterZiv
Member

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

DBA-шник wrote:

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

Уважаемый, к чему эта риторика ? Как это относится к предмету обсуждения,
который и так уже ушел далеко от простого "как откатить транзакцию из
триггера в MySQL" ?

Posted via ActualForum NNTP Server 1.4

26 авг 08, 10:13    [6108240]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
SergSuper
Member

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

Уважаемый DBA-шник!
Вы, безусловно, сильны в аллегориях... ;)
Как ни печально, превращение науки в бизнес прекратить нельзя.
Если Вы не понимаете к чему ведет кибернетику этот синий бренд, взгляните на медицину, в частности - фармацевтику. То, во что она превратилась в сегодняшние дни.

Это ведёт к тому что время разработки сокращается, а продолжительность жизни увеличивается
26 авг 08, 10:37    [6108345]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
MasterZiv
Member

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

hamjak wrote:

Я решил вернуться обратно к конкретным проблемам конкретного человека.

> Написал всю БД в MySQL... но потом выяснилось что в триггерах невозможно
> использовать операторы отката или завершения транзакции. А мне это

На каких основаниях сделан такой вывод ? Пробовали ?
просто я прочитал сейчас документацию, запрещения ролбэков не нашел,
оно есть только у функций.

> нужно. Вышел из ситуации путем создания исключения(ошибки) в триггере
> BEFORE INSERT.

Так, а исключения чем не нравятся ? Поймаете, и откатите.

Да , какой engine используете ?

> FireBird еще не пробовал.

Если вы будете работать в FB, то там вам реально есть смысл не откатывать
транзакцию в триггере, а делать это в вызывающей процедуре или на
клиенте, как тут многие советовали. Для FB такой подход нормален.

Posted via ActualForum NNTP Server 1.4

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

Откуда:
Сообщений: 11551
pkarklin
hvlad
Потому что тр-цию не триггер начинал. И не ему делать вывод об её окончании.


В Вашем высказывании подспудно прослеживается мысль: "Кто начал транзакцию - тот ее и должен закончить". Я не прав?
Даже не подспудно, а совершенно явно :)

pkarklin
Объясните, почему сервер, в случие определенных ошибок может принять решение об откате транзакции? Не он же ее начинал? Это его дело?
Я и пишу - не может, если не он её начинал. Где Вы прочли обратное ?
Единственный случай - фатальный сбой сервера или отвал клиента, но мы не об этом.

pkarklin
Тогда почему триггер не имеет прав, выполнив определенную проверку и найдя нарушения той или иной "целостности", сделать откат транзакции, начатой явно или неявно?
Потому что не он её начинал. Всё, что он может - вызвать исключение, по которому сервером безусловно откатывается оператор, вызвавший срабатывание триггера. Судьба же всей тр-ции - в руках вызывающего кода.
Если это была неявная тр-ция, то она неявно начиналась сервером и им же и откатится. Но явные тр-ции трогать не нужно и не должно.

pkarklin
Каким основопологающим принципам (и где они записаны) противоречит такой подход? Только тем, что некоторые СУБД не позволяют этого сделать?
Я уже писал - нарушение изолированности слоёв ПО.
Поверьте на слово, добавить возможность явного отката тр-ции в FB - дело на полчаса. Но никто в здравом уме не пропустит такое в код.

pkarklin
hvlad
А вот с принудительным роллбеком тр-ции - никто не может ничего в ней сделать, кроме попытки повтора операции в другой тр-ции.


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

pkarklin
Зачем еще изобретать какие-то обработчики ИС на каких-то промежуточных звеньях, если серверная сторона полностью контролирует все эти исключительные ситуации и их обработку?
См. выше - не полностью.
26 авг 08, 10:56    [6108479]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
MasterZiv
Member

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

Bogdanov Andrey wrote:

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

Так, это что за принцип такой ? Где описан ?
В стандарте ? Ссылки пожалуйста давайте. А если нигде -
то это ваши выдумки, извините. Ваши личные принципы организации
ПО. Почему им все должны следовать ?

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

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

Posted via ActualForum NNTP Server 1.4

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

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

hvlad wrote:

>
> Которую вы тут же и придумали. Вот если бы это было нарушение стандарта,
> или ещё чего-то специфицированного, тогда был бы разговор.
> А так - это просто ваши личные измышления. Мои могут быть другими.
> Ещё кого-то - третьими.
>
> Что я придумал ? Что роллбэк в триггере, а не в точке старта тр-ции
> нарушает изолированность слоёв ПО ?

Вы придумали это :

Хорошо спроектированный софт всегда разбит на слои, максимально изолированные
друг от друга. Откат тр-ции не в том слое, который её создавал, есть грубейшее
нарушение этой изоляции.

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

Успехов в изучении методологий
26 авг 08, 11:02    [6108518]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
hvlad
Member

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

hvlad wrote:

> Потому что тр-цию не триггер начинал. И не ему делать вывод об её
> окончании.

А кто начинал-то ? Я же уже писал, что если так рассуждать, то и
НАДО откатывать транзакцию в триггере.
А я уже писал, что не надо - и что ?

MasterZiv

> Т.е. если /некий слой/ стартовал тр-цию и запустил в ней запрос с
> процедурой, которая делает инсерт, который вызывает триггер, который
> вызывает другую процедуру, которая ... который вызывает исключение, то
> это исключение _может_ быть обработано в любой из этих
> процедур\триггеров или в /нашем слое/. Этим слоем может быть как
> GUI-клиент, так и апп-сервер, так и процедура на SQL сервере.

А почему не триггер ? Если в ЛЮБОМ слое, то самый последний триггер -
всего лишь низший из этих слоёв. Частный случай хранимой процедуры.
Мы понимаем разницу между обработкой исключений и жестким откатом тр-ции ?
Или Вы всегда обрабатываете исключения вызовом abort() ?
Также советую подумать о том, что процедуры и триггеры совсем не всегда лежат в одном и том же слое ПО. Даже если по способу написания и исполнения они похожи
26 авг 08, 11:10    [6108569]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
pkarklin
Member

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


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

Только не надо снова о "методологиях и принципах". Мы говорим о самодостаточночти и изолированности?
26 авг 08, 11:13    [6108591]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
hvlad
Мы понимаем разницу между обработкой исключений и жестким откатом тр-ции ?


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

Дав ответ на это вопрос мы и получим ответ - имеет право быть ROLLBACK в триггере или нет.

Работать ли при SET XACT_ABORT OFF и обрабатывать исключение, которое может возникнуть на любой инструкйии транзакции или откатывать ее всю при исключении на любом из операторов.

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

В некоторых случаях достоаточно будет грубого ROLLBACK, а в некоторых детальная обработка в try ... catch...

Поэтому я и против категоричного "нет" ROLLBACK в триггере.

ЗЫ. И не надо плевать в сторону мелкомягких. Такая возможность существует во многих СУБД.
26 авг 08, 11:20    [6108628]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Bogdanov Andrey
Member

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

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

pkarklin
Bogdanov Andrey
Разработчик бд никакого представления отом, что в этой транзакции происходило, то есть он принял решение об откате сам не знает чего.


Здрастье - приехали. Он принял решение об откате того, что привело бы к нарушению целостности данных. Это для Вас не является аргументом для отката транзакции?

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