kdv
То есть, вот этот какой то бредовый наезд, что из триггера на таблицу эту же таблицу ну никак нельзя модифицировать, я считаю порождением факта о мутирующих таблицах в Оракле, и ничем иным. Для Вас, похоже, авторитет Оракла настолько непререкаем, что Вы даже и усомниться в его функционировании не можете.
Помню, была совершенно идиотская битва с MS SQL-цами, на тему, зачем нужно вообще в одном коннекте стартовать несколько транзакций одновременно, и боже сохрани, иметь в одной транзакции несколько открытых курсоров с возможностью поочередного фетча.
Это просто не укладывалось в их мозгу, потому что этого НЕТ в MS SQL, а значит и НЕ ДОЛЖНО быть ни в какой другой СУБД.
Вы аналогичные мысли пытаетесь проталкивать?

С таким же успехом можно было сказать, что текущую функциональность Firebird благословил Господь, и все кто усомнились в ее праведности, есть еретики. Но этого же нет. С вами пытаются вести дискуссию разработчики Firebird, которые, уверяю, имеют опыт работы как с Ораклом так и с MS SQL, и внимательно изучают в т.ч. и их тонкости функционирования.
Впечатление такое, что Вы находитесь в какой-то иной плоскости, которая сродни религиозному фанатизму. Прошу Вас, разуверьте меня, скажите, что Вам в Oracle нравится не все.
Мне вот, в ФБ действительно нравится не все.

И это Вы мне объясняете про бред и домыслы ???
Успокойтесь, можно модифицировать таблицы из их же триггера. Способ еще в 7 Oracle придумали, если склероз мне не изменил. Просто при этом надо отчетливо понимать, ччто именно ты делаешь, но это ведь Вас не должно пугать ???

protector

Gluk (Kazan)


Ты сделал 8 постов подряд. Нельзя было ответить в одном? Хочешь чтобы и
другие отвечали 1 постом на каждую твою фразу?



По делу есть что сказать?

Dimitry Sibiryakov
protectorНельзя было ответить в одном?
Ну, ты же знаешь, когда понос подпирает...

Конечно, радует, что хитрые пользователи к седьмой версии нашли лазейку в клетке, которую
для них воздвигли индусы...


Вы возможно не в курсе дела :)

1. Тригеры в Oracle нынче писать не принято. Помимо озвученных и неозвученных их ограничений, это еще и удар по производительности
2. Голые DML (а для чего еще триггеры ) из приложений тоже вызывать не принято
3. Все что можно сделать триггерами, еще лучше можно сделать грамотно спроектировав API на ХП (как правило в пакетах, но в данном случае не суть)
4. Проблема с мутациями (как и некоторые другие проблемы) в этом случае не возникает
5. Если кому то (мне например) повезло с тяжким Legacy на триггерах, способ обхода таки известен со времен 7 Oracle (желающие могут погуглить на тему обход мутаций в триггере)

А теперь хотелось бы таки услышать ответ на мегаволнительный вопрос:

Если в FB одна транзакция инсертит-комиттит ровно по 100 записей, а другая считает количество записей при помощи count(*), может ли случиться, что она подсчитает некратное 100 число.
Ответ да меня устроит без объяснений, к ответу нет хотелось бы видеть минимальные комментарии

eBaseGluk (Kazan)Dimitry Sibiryakov
artemanaпроблемы, вызваные мутацией, неизбежны.

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


Ой, да ну бросьте. Можно к ним обращаться. И писать можно (геморойно правда).
Вот намедни заказчик осчастливил.

1. Имеется таблица, все действия с которой, записывают копию строки в таблицу журнал
2. Записи собираются из основной таблицы и журнальной по union all
3. Выясняется, что записи в журнале тоже можно редактировать (такой вот хитрый заказчик)
4. Куда бы вы думали журналируются изменения журнальных записей ???

Правильно, в ту же журнальную таблицу. Что вы, серьезно думаете, что мутация кого-то остановила ???И что Вы там говорили про бомбу замедленного действия у kdv? Или Вы думаете что Ваша никогда не рванет?

С чего-б ей рвать-та?
Кто Вам с kdv вообще сказал, что я против записи в таблицу из ее-же триггера???

protector

Dimitry Sibiryakov
Ну, ты же знаешь, когда понос подпирает...

Конечно, радует, что хитрые пользователи к седьмой версии нашли лазейку в
клетке, которую
для них воздвигли индусы...


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



Ну шо я могу сказать ... фигово ты знаешь Oracle. Этому финту первым делом студентов учат

hvladGluk (Kazan)1. Тригеры в Oracle нынче писать не принято. Помимо озвученных и неозвученных их ограничений, это еще и удар по производительности
2. Голые DML (а для чего еще триггеры ) из приложений тоже вызывать не принято
3. Все что можно сделать триггерами, еще лучше можно сделать грамотно спроектировав API на ХП (как правило в пакетах, но в данном случае не суть)Мгм... наверное я таки не в курсе... но
Почему PL\SQL в случае (1) есть удар по производительности, а в случае (3) - не удар ?

PS Я тоже сторонник работы только через процедуры
PPS (3) в общем случае неверно, но не хотелось бы устраивать очередной спор ещё и по этому поводу

Ну к примеру возьмем журналирование изменений по update-у (пример чисто иллюстративный)

1 вариант (традиционный):

Из приложения update-им много строк, каждая из которых активирует триггер, переключая SQL в PL/SQL. В триггере, в свою очередь идет insert, переключая PL/SQL в SQL

2 вариант:

Из хранимки дергаем два DML-я. Первым update-им строки, вторым вставляем изменения в лог.
Всего имеем два переключения PL/SQL в SQL. Независимо от количества изменяемых строк.

Менее умозрительный пример:

Выносим нафих все триггеры, генерирующие PK в те места в ХП, в которых собственно выполняем вставку. В случае если insert-ится большое количество записей, получаем нефиговый выхлоп по производительности :)

hvlad
Concurrency (оно-же snapshot, оно-же умолчательное) - нет

Волнение снято ? Ну, хотя-бы мега- ? :)

Честно говоря не очень :(
Т.е. в случае snapshot мы можем видеть изменения сторонних транзакций не атомарными ??? o O
Т.е. в принципе в примере с переводом денег (из букваря) теоретически есть возможность увидеть переводимую сумму сразу на двух счетах или ни на одном ???

Gluk (Kazan)hvlad
Concurrency (оно-же snapshot, оно-же умолчательное) - нет

Волнение снято ? Ну, хотя-бы мега- ? :)

Честно говоря не очень :(
Т.е. в случае snapshot мы можем видеть изменения сторонних транзакций не атомарными ??? o O
Т.е. в принципе в примере с переводом денег (из букваря) теоретически есть возможность увидеть переводимую сумму сразу на двух счетах или ни на одном ???

Sorry, в Read Committed конечно

vadiminfohvlad
PS Я тоже сторонник работы только через процедуры

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

Сторонники процедур не открывают DML напрямую.
Некоторые сторонники не открывают даже select (но я к ним не отношусь)