Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
 А могуч ли Oracle  [new]
andrushok
Member

Откуда: от верблюда
Сообщений: 7430
Привет Всем.
Тут на меня вроде наехали, может случайно.

www.sql.ru/forum/actualthread.aspx?bid=1&tid=96427

Я не хотел бы продолжать такой широкий вопрос в деревянной теме, давайте попробуем в отдельном топике =). Я в MS SQL Server не такой уж дока, всего с ноября прошлого года его пинаю. А в Oracle с 1996г. Так что есть конечно и корыстный интерес про MS узнать побольше =). Так вот, я буду на MS наезжать, а Вы его защищайте. НУ если хотите, наезжайте на Oracle - тады я его попробую защитить.

Только сразу несколько положений
1) Oracle дороже (раза так в 3 будет в среднем). И возможностей у него поболе будет. Я как бы в более выгодном положении сразу оказался =). Так что счет вести один к одному нечестно - я согласен.
2) Oracle - для юникса в основном (да я собсвтвенно только на юнихе его и пинал). Так что GUI у него нема, кому command line как дебри Амазонки, а GUI надо позарез - идите к жабе TOAD, там усе найдете.
3) На личности переходить не стоит, не я и не Вы Oracle c MS писали. Не нами это придумано (к большому сожалению кстати).


Ну так вот 2 первых проблемы:

I. Я тут с деревом развлекался. Ну и наваял одну stopred procedure, где влепил
WHILE 1=1
BEGIN
  IF something
     BREAK
  ... INSERT something
END 
Ну вобщем сам дурак. Кады отлаживали, все вроде ничего. А кады на QA сервер поставили и тестировщики уже по серьезному дергать стали - она у меня и зациклилась. Я ентот просесс нашел, а вот убить никак не удавалось. Я ему kiil, а ему по барабану. Два дня сволочь висел с диагностикой KILLED но был жив. В конце концов в Transaction Logs кончилось место и он умер сам. Сервер конечно можно было перегрузить, но не позволили. Там еще куча баз болталось. Так вот, можно ли в MS перегрузить базу без перегрузки сервера? Oracle это делает без проблем, в крайнем случае командой kill все убиваешь, а базу потом стартуешь.

II. База у меня развесистая, однако. Я там много всяких DataFile понакрутил. Мол BLOBs в одних лежит, INDEXes в других, данные в третих. TRansaction Logs на другом драйве, все по науке. Тут возникла задачка енту базу скопировать на другой сервер (Так у нас принято, с девелоперского на QA, потом с QA на боевой). Как я не бился, не хотел MS всю енту структуру копировать. Схему - пожалуйста, а вот все навороты ручками надоть. Так что пришлось мне все енти DTT в помойку, и самому скриптик наваять. Что касается Oracle - структуру TABLESPACE ручками тоже создавать надоть. Вот только команды imp и exp умнее немного. Схему копируют уже с учетом размещения в TABLESPACE. A MS все в PRIMARY валит.


Ну пока усе. Я может конечно и сам не во всем разобрался и наехал зря, так что заранее извиняюсь. Буду даже очень рад узнать побольше.
1 июн 04, 06:46    [712509]     Ответить | Цитировать Сообщить модератору
 Re: А могуч ли Oracle  [new]
tpg
Member

Откуда: Novosibirsk
Сообщений: 23902
автор
НУ если хотите, наезжайте на Oracle - тады я его попробую защитить.

А зачем наезжать? Пущай живет.

автор
Oracle дороже (раза так в 3 будет в среднем). И возможностей у него поболе будет.

А вот здесь неплохобы ИМХО ставить.
ИМХО, и тот и другой одного поля ягоды, прошли те времена, когда ораклоиды кичились своей мощью, на MS тоже СББД живут.

автор
а GUI надо позарез - идите к жабе TOAD, там усе найдете.

Да вроде уже, где то в новостях читал, что оракуль эмэсу сдался и заключили они какую то договоренность по поддержке ораклом дотнета. Так чта жабу, похоже на помойку (ИМХО).

автор
Я тут с деревом развлекался.

С деревьми в скуле действительно не всё в поряде. Ждем-с гЮкона! Там обещались всё по полной программе!
Хотя, вот пара ссылок
http://sdm.viptop.ru/articles/sqltrees.html
http://rdbms.narod.ru/article/tree/index.html

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

А про это вам вроде уже в другой ветке отвечали.
1 июн 04, 07:43    [712543]     Ответить | Цитировать Сообщить модератору
 Re: А могуч ли Oracle  [new]
АлексейК
Member

Откуда: http://www.msdatabase.ru , Moscow
Сообщений: 7683
автор
А кады на QA сервер поставили и тестировщики уже по серьезному дергать стали - она у меня и зациклилась. Я ентот просесс нашел, а вот убить никак не удавалось.


что то не верится что в оракле нет понятия стоимсть выполнения запроса или таймаут выполнения запроса...
1 июн 04, 09:00    [712626]     Ответить | Цитировать Сообщить модератору
 Re: А могуч ли Oracle  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 32174
2tpg

автор
С деревьми в скуле действительно не всё в поряде. Ждем-с Юкона! Там обещались всё по полной программе!


Я про это уже отвечал в том топике. Повторю:

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

Использование структуры ID, PARENT_ID в любом случае неэффективно, хоть в оракле, хоть в MSSSQL.

Если у вас к деревьям нет массовых и сложных обращений, то в MSSQL нужно просто написать ф-цию выборки подветки.
А если есть - нужно использовать другие структуры данных.

Юкон действительно позволит написать выборку поддерева одним запросом, но это будет не быстрее, чем в цикле, ну и в тыщи раз медленнее, чем использование альтернативных структур.

На мой взгляд, такие возможности будут способствовать ухёдшению кода - зачем думать, если есть команда? Это то-же самое, что триггеры на строку - их даже нельзя назвать удобными, за редкими исключениями, но народ только их и будет использовать, когда появится.
1 июн 04, 11:37    [713158]     Ответить | Цитировать Сообщить модератору
 Re: А могуч ли Oracle  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
автор
Юкон действительно позволит написать выборку поддерева одним запросом, но это будет не быстрее, чем в цикле, ну и в тыщи раз медленнее, чем использование альтернативных структур.

Гм, не уверен в этом высказывании. Я находясь в предЮконовском состоянии, т.е. работая на Sybase ASA, которая где то на пару шагов по фичам идет впереди MSSQL могу немного представить себе Юкон :)
Так как в Юконе будет реализован механизм COMMON TABLE EXPRESSION так же, как в Sybase ASA, то следующий запрос:
  // Выдать дерево подразделений предприятия
  WITH RECURSIVE HStruct (Node_id, Parent_id, Object_id, Level, Path ) AS (
    SELECT s.Node_id, s.Parent_id, s.Object_id, 0, s.Node_id AS Path
    FROM Struct s
    WHERE s.Parent_id IS NULL
    UNION ALL
    SELECT u.Node_id, u.Parent_id, u.Object_id, Level + 1, h.Path || '/' || u.Node_id AS Path
    FROM Struct u
      INNER JOIN HStruct h ON u.Parent_id = h.Node_id
    WHERE u.Parent_id IS NOT NULL
  )
  SELECT h.Node_id, h.Parent_id, o.Object_id, Space(h.Level * 5) || o.ObjectName as ObjectName
  FROM Object o
    INNER JOIN HStruct h ON o.Object_id = h.Object_id
  ORDER BY Path;
Будет при выборке гораздо эффективнее, чем цикл и времянки, так как в нем оптимизатор использует специализированные алгоритмы Recursive Hash Join и Recursive Union, да еще с учетом статистики. В тоже время альтернативные структуры конечно будут быстрее, но если вспомнить затраты на их поддержку, то это получается накладным для деревьев малого и среднего обьема.

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

Это как их готовить :) Для AFTER операций конечно EACH STATEMENT триггера являются предпочтительней, но для проведения предварительных проверок или дополнительной инициализации полей BEFORE EACH ROW триггера в ASA опять же зарекомендовали себя неплохо, например:
CREATE TRIGGER Table1_Valid BEFORE INSERT, UPDATE
ORDER 1 ON Table1
REFERENCING NEW AS NewValue
FOR EACH ROW
WHEN (
  NewValue.Field1 = 1 AND
  NewValue.Field2 IS NOT NULL
)
BEGIN
  NewValue.Field2 = Upper(NewValue.Field2);
END;
И после такого триггера хоть убейся, но при Field1 = 1 в Field2 всегда будет стринг в верхнем регистре. Очень удобны кстати бывают такие триггера, позволяют иногда убрать логику с ХП, снимая с клиентов обязанность проводить изменения через них и 100% гарантируя правильность содержимого полей таблиц.

Так что Юкон в принципе делает то, что уже давно есть и отработанно в той же ASA. Например, та же поддержка Java не только в кач-ве ХП, но и на уровне сериализации обьектов Java в поля таблицы и работа с ними через SQL в Юконе будет тоже самое насколько я понимаю, но только вместо Java подключат .NET . И не надо говорить, что фичи в Юконе будут бесполезные - очень даже полезные, другое дело что не все ими будут пользоваться правильно, но это по моему к любой СУБД применимо - садомазохистов и велосипедистов всегда хватало и не только в нашей стране :)
1 июн 04, 12:18    [713312]     Ответить | Цитировать Сообщить модератору
 Re: А могуч ли Oracle  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 32174
2ASCRUS

автор

Гм, не уверен в этом высказывании.
...
Будет при выборке гораздо эффективнее, чем цикл и времянки, так как в нем оптимизатор использует специализированные алгоритмы Recursive Hash Join и Recursive Union, да еще с учетом статистики.


К сожалению, не могу делать выводы на основании 1-ой беты юкона - неизвестно, что будет в релизе.

Но в принципе - откуда возьмётся сильно бОльшая эффективность? Принципиально схема одна - енжин делает циклы по уровням. В ядре они, конечно, быстрее, но не в разы или тем более не на порядки. Единственный сильный ход - это сделать специальные индексы для деревьев (т.е. фактически упомянутые специальные структуры), но этого не сделано хотя-бы потому, что используется механизм COMMON TABLE EXPRESSION, т.е. механизм общего типа, а не специальный на деревья (например, можно было в Юконе сделать отдельный рекурсивный FK-констрэйн, по которому строились-бы такие индексы).

Затраты на их поддержку очень незначительные, если правильно их готовить :-)
Фактически, затраты на их поддержку превышают выгоду от них только если выборок данных меньше модификаций. Структура left-right для вставки или перемещения поддерева требует одного апдэйта - хорошо подходит для небольших деревьев. Есть структуры и для больших.

Насчёт триггеров BEFORE для набора - не понимаю, почему они не эффективнее построчных???

Если ваш построчный триггер:
CREATE TRIGGER Table1_Valid BEFORE INSERT, UPDATE
ORDER 1 ON Table1
REFERENCING NEW AS NewValue
FOR EACH ROW
WHEN (
  NewValue.Field1 = 1 AND
  NewValue.Field2 IS NOT NULL
)
BEGIN
  NewValue.Field2 = Upper(NewValue.Field2);
END;

Заменить на некий гепотетический групповой триггер BEFORE, в котором можно менять таблицу inserted, то чем он хуже или медленнее? Ведь на каждую из изменяемых строк из тысячи в построчном триггере придётся выполнить запрос, а запрос ведь может быть и сложным.

CREATE TRIGGER Table1_Valid BEFORE INSERT ON Table1
AS 
BEGIN

  UPDATE inserted
  SET Field2 = Upper(Field2)
  WHERE
      Field1 = 1 AND
      Field2 IS NOT NULL

END

Т.е. поймите меня правильно - я не против BEFORE триггеров, я против введения триггеров FOR EACH ROW - это сильно ухудшит общее качество кода, я против VB-лизации SQL-сервера :-).
При этом не забудьте, что триггер FOR EACH ROW - это не дополнительная фунуциональность, это просто чтобы не писать лишние пару строк для курсора.
1 июн 04, 14:14    [713763]     Ответить | Цитировать Сообщить модератору
 Re: А могуч ли Oracle  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
автор
Но в принципе - откуда возьмётся сильно бОльшая эффективность? Принципиально схема одна - енжин делает циклы по уровням. В ядре они, конечно, быстрее, но не в разы или тем более не на порядки. Единственный сильный ход - это сделать специальные индексы для деревьев (т.е. фактически упомянутые специальные структуры), но этого не сделано хотя-бы потому, что используется механизм COMMON TABLE EXPRESSION, т.е. механизм общего типа, а не специальный на деревья (например, можно было в Юконе сделать отдельный рекурсивный FK-констрэйн, по которому строились-бы такие индексы).

Ну выгода получается только при обработке малых и средних деревьев специальным механизмом оптимизатора HASH, который на основе индекса на Parent_id может построить хэш таблицу вхождений и далее использовать ее. В остальном полностью согласен, специальный индекс не помешал бы. В приниципе в ASA можно заявить о требовании расширения такой функциональности на их специализированном форуме Futures, но для этого должно подписаться достаточно народу, чтобы разработчики ASA поставили себе такую задачу в план расширения версий. Пока насколько я понимаю никто на ASA сверхсложные деревья не обрабатывал, поэтому никто и не просил :) Хотя их форум работает достаточно эффективно и доказательством этому можно привести их ежемесячные патчи, в которых не только исправляются найденные пользователями ошибки (к примеру мои 4 заявленных в конце февраля бага при отработке с довольно специфической логикой скриптов были в апрельском патче уже поправлены), но и расширение функциональности (например ввод OLAP функций и SELECT-ов с поддержкой OVER ... PARTITION BY ... RANGE, насколько я понимаю слизанных у Оракла). Я вот лично все подумываю, что для хорошей жизни мне в ASA не хватает event-ов на DDL операторы (в Юконе вроде как на DDL заявлена поддержка триггеров). Непонятно только как мотивировать такую функциональность и с кем сравнить, если ее еще ни у кого нет (или уже у кого есть ?).

автор
Т.е. поймите меня правильно - я не против BEFORE триггеров, я против введения триггеров FOR EACH ROW - это сильно ухудшит общее качество кода, я против VB-лизации SQL-сервера :-).
При этом не забудьте, что триггер FOR EACH ROW - это не дополнительная фунуциональность, это просто чтобы не писать лишние пару строк для курсора.

Мой приведенный пример будет работать один в один так же, как если бы я все сделал курсором в EACH STATEMENT триггер. Фактически ASA перед операцией вызывает BEFORE TRIGGER для каждой записи, подходящей в условие триггера WHEN, любые изменения полей фиксирует в этот набор записей, только после этого делает все проверки CONSTRAINTS (проверки FOREIGN KEY кстати могут отложиться до COMMIT, если для него указана опция CHECK ON COMMIT, полезная фича для деревьев). Далее уже происходит физическая запись изменений в таблицу и потом вызываются AFTER триггера. При таком раскладе если использовать BEFORE EACH ROW триггера только для проверок или модицикаций полей с одной стороны накладных расходов не возникает, т.к. все это происходит на уровне самой ASA, я не организовываю курсоры и т.д. (да и вообще пока ничего не произошло, Inserted и Deleted как таковых физически нет), с другой стороны это позволяет мне например возбудить ошибку до того, как СУБД начнет какие либо операции с данными (это явно лучше, чем обновить миллион записей и потом надумать делать ROLLBACK TRIGGER) или например установить значение в поле для того же Primary Key, хотя с клиента шло NULL, тем самым избежав ошибки и навязав свою логику. Ну а для AFTER триггеров позаписные триггеры понятное дело извращение, тут как раз самое выгодное FOR EACH STATEMENT и обработка всего множества изменившихся записей запросами, а не курсором (про использование DML в BEFORE FOR EACH ROW я вообще лучше промолчу - это из области "Запрос на изменение большого кол-ва данных длинной в жизнь"). Так что исходя из вышесказанного я лично не против TRIGGER BEFORE FOR EACH ROW, я против их неправильного использования :) Нельзя ставить в вину СУБД, что она много умеет - умельцы везде найдутся. Вот например в ASA в UDF разрешено все, что и в ХП (в отличие от MSSQL). Сразу возникает вопрос - "Как много людей постараются написать UDF с использованием курсоров, вызовов ХП или динамическим SQL, а потом использовать эти функции в запросах ?". Ответ будет очевидным - достаточно много, во всяком случае не меньше чем в том же самом Оракле (в процентном отношении конечно общего кол-ва разработчиков этих СУБД). Однако с другой стороны вопрос "Насколько отсутствие в MSSQL BEFORE TRIGGER-ов или в Оракле TRIGGER FOR EACH STATEMENT будет печальным для меня" ответ будет таким: "Печально, гемморно из за лишнего кода, возможно не красиво, но не смертельно, если я хорошо знаю MSSQL или Оракл".

Так что лично я ратую обоими руками как за Оракл, так и за MSSQL. Развивайтесь на здоровье, реализуйте как можно больше возможностей :) Ну а там, где нужны тиражные или удаленные самоадминистрирующиеся кроссплатформенные СУБД с БД средних размеров, с полноценной гетерогенной репликацией (вплоть до off-line) с другими СУБД и мобильными решениями, со скромными аппаратными требованиями и ценой, плюс поддержкой различных наворотов современных СУБД, лучше вспомните о той же Sybase ASA, именно с такими спецификациями она и заявлена. Во всяком случае в забугорье так и есть: консолидированные БД на Ораклах, удаленки и задачи мелко-среднего бизнеса на ASA (с MSSQL такого нет, тут конкурирует удачная реализация MSDE, так что однозначнее выгоднее держать связку MSSQL Enterprise + MSDE). Для информативности даю ссылку на тех описание ASA: http://www.ianywhere.com/downloads/datasheets/SQL_Any_datasheet_0526.pdf , на основе собственных решений и проектов моих коллег по России и СНГ, могу только добавить, что документ не является рекламной брошуркой и соответствует действительности.
1 июн 04, 16:01    [714199]     Ответить | Цитировать Сообщить модератору
 Re: А могуч ли Oracle  [new]
Zaxx
Guest
2 andrushok

>Oracle дороже (раза так в 3 будет в среднем).

Откуда такие цифры ??? Может на 30 процентов, а не в 3 раза ?

>Я ему kiil, а ему по барабану. Два дня сволочь висел с диагностикой KILLED но был жив.

А слабо воспользоваться утилиткой ORAKILL ?

>а GUI надо позарез - идите к жабе TOAD, там усе найдете

А enterprise manager у oracle довольно для вас недостаточно GUI-ВЫЙ ?
1 июн 04, 16:24    [714284]     Ответить | Цитировать Сообщить модератору
 Re: А могуч ли Oracle  [new]
alex_k
Member

Откуда: krasnoyarsk
Сообщений: 6694
я поражаюсь.
люди читают и видят в прочитанном только отражение своих мыслей.
1 июн 04, 16:45    [714350]     Ответить | Цитировать Сообщить модератору
 Re: А могуч ли Oracle  [new]
andrushok
Member

Откуда: от верблюда
Сообщений: 7430
2 Zaxx
Zaxx
А слабо воспользоваться утилиткой ORAKILL ?


Ну и как ORAKILLом прибить процесс на MS SQL?

2 АлексейК
АлексейК
что то не верится что в оракле нет понятия стоимсть выполнения запроса или таймаут выполнения запроса...


Аналогично, Oracle тут и не пахнет...

Всем спасибо, расширяет кругозор однако.

2 Zaxx
Zaxx
А enterprise manager у oracle довольно для вас недостаточно GUI-ВЫЙ ?




- Умеете ли Вы играть на скрипке?
- Не знаю, не пробовал ...


Извините меня, я испорчен юнихом... Дальше command line и vi не вижу.
1 июн 04, 18:40    [714772]     Ответить | Цитировать Сообщить модератору
 Re: А могуч ли Oracle  [new]
Zaxx
Guest
2 andrushok

>Ну и как ORAKILLом прибить процесс на MS SQL?

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

>Извините меня, я испорчен юнихом... Дальше command line и vi не вижу.

Но TOAD - то вы однако умудрились увидеть, несмотря на испорченность юниксом. И вероятно, проще посмотреть на родные ораклиные средства администрирования, чем на TOAD и ему подобные. Хотя-бы потому, что за них уже заплачено...
1 июн 04, 22:25    [715055]     Ответить | Цитировать Сообщить модератору
 Re: А могуч ли Oracle  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
>Да вроде уже, где то в новостях читал, что оракуль эмэсу сдался и заключили они какую то договоренность по поддержке ораклом дотнета. Так чта жабу, похоже на помойку (ИМХО).

А мне понравился вот этот классический случай, когда чел. даже не вьехал о чем речь, но дал умный совет :))
1 июн 04, 22:36    [715065]     Ответить | Цитировать Сообщить модератору
 Re: А могуч ли Oracle  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
автор
Т.е. поймите меня правильно - я не против BEFORE триггеров, я против введения триггеров FOR EACH ROW - это сильно ухудшит общее качество кода, я против VB-лизации SQL-сервера :-).
При этом не забудьте, что триггер FOR EACH ROW - это не дополнительная фунуциональность, это просто чтобы не писать лишние пару строк для курсора.

Это не дополнительная функциональность, это дополнительная степень свободы. Пример: на триггере реализован контроль целостности. И зачем полностью исполнять удаление 500.000 записей из таблицы в 50.000.000 только ради того, чтобы убедиться в невыполнении условий целостности и откатить все удаление?

Да, иногда row-level триггера дороговаты. Иногда - разумны. В этом случае нужно учить правильному использованию фичи, а не запрещать фичу потому, что ей можно воспользоваться неправильно.
2 июн 04, 18:22    [717486]     Ответить | Цитировать Сообщить модератору
 Re: А могуч ли Oracle  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 32174
2softwarer, ASCRUS

Ну вот, опять не поняли меня :-(((

Вы, и softwarer и ASCRUS, пишите совсем про другое - я вам говорю не о before и after триггерах, а о триггерах на строку и на стэйтмент!

softwarer

Это не дополнительная функциональность, это дополнительная степень свободы.
Пример: на триггере реализован контроль целостности. И зачем полностью исполнять удаление 500.000 записей из таблицы в 50.000.000 только ради того, чтобы убедиться в невыполнении условий целостности и откатить все удаление?


Так это относится к функциональности, а не к степени свободы! Это - про различия в BEFORE и AFTER триггеров!

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

Не лучьше-ли вызвать BEFORE триггер, в нём ОДНИМ запросом проверить целостность записей, и потом уже начать удаление?

автор
Да, иногда row-level триггера дороговаты. Иногда - разумны. В этом случае нужно учить правильному использованию фичи, а не запрещать фичу потому, что ей можно воспользоватьсянеправильно.


Если говорить про row-level и statement-level BEFORE триггера, то единственное отличие - не нужно писать курсор - он уже есть в ДБ-енжине. Я не могу придумать примера, в котором они разумны.

Ещё раз про пример, который я привёл ASCRUS-у

Если ваш построчный триггер:

CREATE TRIGGER Table1_Valid BEFORE INSERT, UPDATE
ORDER 1 ON Table1
REFERENCING NEW AS NewValue
FOR EACH ROW
WHEN (
  NewValue.Field1 = 1 AND
  NewValue.Field2 IS NOT NULL
)
BEGIN
  NewValue.Field2 = Upper(NewValue.Field2);
END;

Заменить на некий гепотетический групповой триггер BEFORE, в котором можно менять таблицу inserted, то чем он хуже или медленнее? Ведь на каждую из изменяемых строк из тысячи в построчном триггере придётся выполнить запрос, а запрос ведь может быть и сложным.

CREATE TRIGGER Table1_Valid BEFORE INSERT ON Table1
AS 
BEGIN

  UPDATE inserted
  SET Field2 = Upper(Field2)
  WHERE
      Field1 = 1 AND
      Field2 IS NOT NULL

END
2 июн 04, 18:52    [717583]     Ответить | Цитировать Сообщить модератору
 Re: А могуч ли Oracle  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
автор
Заменить на некий гепотетический групповой триггер BEFORE, в котором можно менять таблицу inserted, то чем он хуже или медленнее? Ведь на каждую из изменяемых строк из тысячи в построчном триггере придётся выполнить запрос, а запрос ведь может быть и сложным.

Ну во первых долгие запросы в BEFORE выполнять нехорошо, операция изменения данных уже запущена, но физической записи в таблицу еще нет. А значит и нет Inserted, т.е. запрос то делать не по чему. Задача в BEFORE максимально быстро сделать прединициализацию операции изменения или обработать ошибки, продотвратив дорогостоящую операцию изменения данных.

Я даже кстати могу точно для ASA 9 сказать, что BEFORE вызываются прямо во время выполнения запроса изменения, т.е. сразу же после проведения блокирования записи, что позволяет при возбуждении ошибки в таком триггере не только отказаться от операции записи, но и предотвратить дальнейшее блокирование данных, что неплохо в тех ситуациях, когда мы изменяем огромное кол-во записей и сразу же наткнулись на ошибку. Думаю Вы согласитесь со мной, что для блокировочника здесь явно перевешивает возможность уменьшения стоимости и длительности блокировок, а не отсутствие BEFORE FOR EACH STATEMENT, для реализации которого ASA пришлось бы сначала все блокировать и только потом решать, все правильно или нет :)

P.S. В доке естественно ничего такого про низкоуровневую работу триггеров BEFORE нет, все проверенно лично мной эксперементальным путем. Хотя как я заметил, если об этих особенностях к ним на форум писать, то в последующем EBF документация по ним аккуратно появляется в BOL. Вот жуки то :)
2 июн 04, 23:56    [717875]     Ответить | Цитировать Сообщить модератору
Все форумы / Сравнение СУБД Ответить