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

Откуда: Санкт-Петербург
Сообщений: 3004
Очевидно проблемы у MS SQL.

таблица называется inserted, а не updated.

Ну ошибся человек - с кем не бывает.

Проблема сопоставления записей в inserted & deleted действительно есть, но
только в случае изменения первичного ключа и обновления нескольких записей одним UPDATE-ом.

Сколько их ни просили сделать "псевдоколонку" типа ROWID - ни в какую, кое-кто даже предполагал что они боялись в какие-нть темные углы кода унаследованного от Sybase лезть ;-)
До сих пор кста не сделали!

Однако если использовать identity в качестве первичного ключа, то можно смело соединять inserted и deleted - сопоставление однозначное ибо первичный ключ не меняется.

Так что тут не MS виноват - а ручки что базу рисовали ;-)
22 окт 04, 17:45    [1055645]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
funikovyuri

Так у кого были проблемы с тригерами? У MS SQL или Oracle? Если у MS SQL то там во-первых никогда таблицы updated не было, во-вторых ничего никуда отсоединять не надо...


Ну уже забывать стал. Вместо updated была inserted. Но не в названии дело, а способе получения инфы про то, что на что изменилось. Проблемы были у меня при решении той задачи c каскадными обновлениями на MS SQL. В Оракле эту инфу получить проще. Там есть псевдоколнки OLD и NEW, в которых соответственно значение до и после измения.
Не отсоединять а соединять. Т.е. если
А B
1 e
2 g
и транзакция меняет 1 на 8 и 2 на 7, то для того, чтобы во время транзакции в триггере узнать, что 1 изменилось на 8, а не на 7, то надо соедентиь inserted и deleted по полю B. Однако, в ообщем случае это поле должно быть уникальным. Для того, чтобы убедиться, что других вариантов нет я предложил этот триггер сгенерить ERWIN. Потом предложил и для Оракле.
В первом случае сгенеренный триггер работает, только если меняется одна запись (в deleted - одна запись и тогда соединять, естественно, не надо), а во вотором (на Оракле) для любого кол-ва изменяемых записей.
22 окт 04, 17:53    [1055672]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
ASCRUS
Member

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

Я конечно не претендую на роль знатока Оракла, но по моему там триггеров EACH STATEMENT с возможностью доступа к изменяемой информации нет, все только позаписные (EACH ROW) ?
22 окт 04, 18:08    [1055720]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
PL99
Member

Откуда: Moscow
Сообщений: 1367
vadiminfo
В Оракле эту инфу получить проще. Там есть псевдоколнки OLD и NEW, в которых соответственно значение до и после измения.
Пожалуй, все-таки, это не псевдоколонки, а, если угодно, псевдозаписи.

ASCRUS
Я конечно не претендую на роль знатока Оракла, но по моему там триггеров EACH STATEMENT с возможностью доступа к изменяемой информации нет, все только позаписные (EACH ROW) ?
Именно так.
22 окт 04, 19:05    [1055871]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
funikovyuri
Member

Откуда: Симферополь
Сообщений: 4045
ЗоринАндрей & vadiminfo

Однако, в ообщем случае это поле должно быть уникальным.
Да согласен, только я никогда не изменял первичный ключ - так что эти таблицы мне всегда казались очень удобным способом обработки изменившихся данных - и уж точно не недостатком
22 окт 04, 19:49    [1055959]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
ЗоринАндрей
Member

Откуда: Санкт-Петербург
Сообщений: 3004
Ну так а я о чем?!
При грамотном дизайне - проблем нет.
Классическое ->Doctor, doctor, it hurts when I do that.... ... then don't do that.

но все равно - невозможность сопоставить какая запись в inserted какой записи в deleted соответствует - недостаток, однозначно!
22 окт 04, 20:36    [1055998]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
ASCRUS

Я конечно не претендую на роль знатока Оракла, но по моему там триггеров EACH STATEMENT с возможностью доступа к изменяемой информации нет, все только позаписные (EACH ROW) ?

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

PL99

Пожалуй, все-таки, это не псевдоколонки, а, если угодно, псевдозаписи.

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

ЗоринАндрей

При грамотном дизайне - проблем нет.
Классическое ->Doctor, doctor, it hurts when I do that.... ... then don't do that.

но все равно - невозможность сопоставить какая запись в inserted какой записи в deleted соответствует - недостаток, однозначно!

Действительно, я тоже считаю, что в большинстве случаев желательно избегать изменения первичного ключа. Но у проектировшика может быть выбор.
Хотя это уже больше из области проектирования, но все-таки иногда естественный ключ может дать выгоду и при использовании в ограничениях ссылочной целостности.
Представьте три таблицы - Договор, Этап договора и Исполнитель договора. И известно, что в большинстве тяжелых запросов по квартальной и годовой отчетности нужно много данных из второй и третьей таблы, а из первой только номер договора. При этом известно, что номера договоров крайне редко меняются. Тогда Номер договора в качестве первичного ключа в первой табле и внешнего во второй достаточно привлекателен: во многих запросах не будет "лишнего" соединения первой и второй таблиц. А ведь наша цель как можно больше упростить получение необходимой информации.
22 окт 04, 21:53    [1056049]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
ЗоринАндрей
Member

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


Это все теория. А на практике может оказаться что сканирование относительно небольшой таблицы договоров по индексу плюс джойн по эффективному суррогату будет быстрее чем сканирование больших таблиц (да еще и немного "распухших" из-за включения номера договора в каждую запись).
22 окт 04, 22:24    [1056071]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
Alex.Czech
Guest
Шо, таблицы inserted и updated не нравятся ? А сообщение table is mutating вам нравится ? Видать, не пробовали вы никогда триггера-то серьезные на Оракле писать, кто ж там даст-то из таблицы читать в триггерах строчных :) А из statement-level - это чтобы понять что изменилось надо все поля всех строк таблицы куда-то аккуратно до скинуть, а после с этим до сравнить. Добрая задача если записей эдак тыщ 100, такой триггер всякий юзер одобрит.

Я вовсе не планировал Оракл демонизировать тем что выше написано, я только хочу сказать что лично мне как ни странно MS-ные триггера нравятся больше, чем Оракловые, как раз из-за того что там можно работать в statement-level с таблицей изменений... а если мне понадобится row-level, курсорчик объявлю, не маленький. Вот наличие отсутствия before triggers - это конечно позор, можно instead of-ами эмулировать, но позор все равно :) Авось сделают когда-нибудь
23 окт 04, 02:16    [1056213]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Alex.Czech

Шо, таблицы inserted и updated не нравятся ? А сообщение table is mutating вам нравится ? Видать, не пробовали вы никогда триггера-то серьезные на Оракле писать, кто ж там даст-то из таблицы читать в триггерах строчных :)

Вроде выше писал, что из триггеров на уровне строки читать изменяемую таблу нельзя и почему. И вопросы звучат так что, если бы были inserted и updated, то всегда можно было бы получить ту инфу, которою не удается получить из-за table is mutating? Не уверен. Более того, начал с той ситуации, когда возникли трудности. Однако, у Оракла есть механизм автономных транзакций, который если уж так надо позволит прочитать таблу и из такого триггера, конечно, разработчик сам должен на себя взять ответственность за такую транзакцию.
Может и не писал серьезных триггеров, и даже не знаю что понимается под серьезными триггерами. В литературе такого понятия не встречал еще.
Alex.Czech

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

А что же Вы тогда спрашивали про то - нравится ли table is mutating?
Т.е. нет возможности читать про таблу из тыщ 100 из триггеров строчных, причем столько раз сколько записей изменяется. Однако, в общем случае триггера на уровне инструкции и записи могут взаимодействовать. Т.е. триггер на уровне записи может сбросить куда-то что изменилось, а триггер на уровне записи с этим что-то делать. Поэтому остаются разные варианты как триггеру на уровне инструкции узнать что и на что изменилось.

Alex.Czech

Я вовсе не планировал Оракл демонизировать тем что выше написано, я только хочу сказать что лично мне как ни странно MS-ные триггера нравятся больше, чем Оракловые, как раз из-за того что там можно работать в statement-level с таблицей изменений... а если мне понадобится row-level, курсорчик объявлю, не маленький.

Я тоже не собирался демонизировать ничего и MS SQL в частности. Просто мы в любом случае коллеги и должны обмениваться своими знаниями, мнениями, сомнениями и т.д.
23 окт 04, 14:49    [1056472]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
Alex.Czech
Guest
Если я буду на каждую реплику отвечать, а потом вы на каждый ответ, то мы жестоко погрязнем :) Я хотел сказать вот о чем: допустим, мы имеем обычную ситуацию когда по изменению таблицы с деревом (есть поле ID, есть поле ParentID) мне нужно перестроить таблицу-акселератор (есть поле ID, есть поле AncestorID, есть поле Level). Триггер на DELETE для этой задачи выглядит одинаково и в Оракл и в MS SQL, а вот триггеры на INSERT и UPDATE в Оракл представляют собой набор из 3(!) триггеров+дополнительного package-а. Вот за это я и люблю больше триггеры MS SQL. Я не так много хочу от Оракла на самом деле - пусть будут строчные триггера, пусть можно будет в них менять значения вставляемые, это несомненно очень удобно. Но я хочу блин видеть в statement-level триггере какие конкретно строчки изменились в каком бы то ни было виде, иначе все на что он годен это массивчики обнулять которые в after-триггере обработаются или тупые сообщения типа "ой, insert сработал" в лог писать.

Автономные транзакции - это вообще чаще всего граната которую в руки обезьяне сунули (ничего личного, это я не вас имею в виду). Я про них прикладным программистам нашим ничего не рассказываю и надеюсь что они ничего про них сами не разузнают :)
23 окт 04, 22:56    [1056697]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
2 Alex.Czech
Наверное, то я что я сказал про inserted и deleted не совсем так прозвучало как я хотел. Мне не они не нравились, а то что кроме них не было другого простого способа получить инфу. Я про ERWIN потому и упомянул, что искал другой способ. Конечно, чем больше инфы, тем лучше. Но, наверное, плата за такие структуры производительность системы. Возможно для версионника большая плата за такую инфу что в inserted и deleted , чем для блокировочника. Однако псевдозаписи NEW и OLD не просто удобны - это важная инфа, получать которую желательно как можно проще.

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

И среди них автономные транзакции. Ведь они позволяют, например, аудитить неудачные попытки изменения данных. Этого раньше не было. Этого хотели и получили.
24 окт 04, 00:29    [1056722]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
Alex.Czech
Guest
Псевдозаписи NEW и OLD можно легко получить при помощи курсора (в MS SQL). Псевдотаблицы inserted и deleted чтобы получить (в Oracle) надо написать 3 триггера, и в итоге в триггере before все равно ты их не получишь вообще никак (то есть ситуация такая же что и в MS SQL)

В итоге получается что все пресловутые преимущества Oracle над MS SQL по части триггеров for each row - это лабуда.
Правда, есть одно "но" - я не затрагиваю здесь вопросы производительности. По той простой причине что не производил сравнительных тестов. Я знаю что триггеры с курсорами внутри на MS SQL очень сильно замедляют внесение изменений в таблицу. Но вот насчет Oracle ничего не могу сказать
24 окт 04, 03:43    [1056739]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Хе хе - в ASA поступили красивее - сделали и триггеры BEFORE, AFTER FOR EACH ROW с NEW и OLD , и триггеры AFTER FOR EACH STATEMENT с Inserted и Deleted. Получилось и удобно и гибко. И даже для тех, кто привык работать с Oracle или MSSQL привычно :)
24 окт 04, 15:22    [1056867]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
Alex.Czech
Guest
Вот и молодцы ! Не знал, спасибо :)
24 окт 04, 15:59    [1056881]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Alex.Czech

Псевдозаписи NEW и OLD можно легко получить при помощи курсора (в MS SQL). Псевдотаблицы inserted и deleted чтобы получить (в Oracle) надо написать 3 триггера, и в итоге в триггере before все равно ты их не получишь вообще никак (то есть ситуация такая же что и в MS SQL)

Псевдозаписи NEW и OLD легко можно получить с помощью курсора? Нет спасибо. Они слишком часто и в разных ситуациях нужны, чтобы париться с куросорами каждый раз.
Чтобы получить структуры типа inserted и deleted для триггера на уровне инструкции нужен всего один триггер на уровне записи, который будет сбрасывать NEW и OLD в эти структуры. Конечно, нужны процедуры пакета, например, если эти структуры реализуются с помощью коллекций. Специально проверил - написал и протестировал. Или я не понял о чем Вы, когда говорите про три триггера.
Однако, остается вопрос как часто нужны inserted и deleted, если есть псевдозаписи NEW и OLD. Зато другие структур с инфой об изменениях, в которых ясно что на что изменено в каждой записи приходится время от времени реализовывать.

Alex.Czech

Правда, есть одно "но" - я не затрагиваю здесь вопросы производительности. По той простой причине что не производил сравнительных тестов. Я знаю что триггеры с курсорами внутри на MS SQL очень сильно замедляют внесение изменений в таблицу. Но вот насчет Oracle ничего не могу сказать

Так это одно "но" перевесит тысячу других улик (К/ф "Место встречи изменить нальзя").

Alex.Czech

В итоге получается что все пресловутые преимущества Oracle над MS SQL по части триггеров for each row - это лабуда.

Нет, пока еще ничего не получается. Кому как. Кому преимущества, кому нет.
Тем более нет уверенности, что это единственный вопрос об их отличии.

ASCRUS

Хе хе - в ASA поступили красивее - сделали и триггеры BEFORE, AFTER FOR EACH ROW с NEW и OLD , и триггеры AFTER FOR EACH STATEMENT с Inserted и Deleted. Получилось и удобно и гибко. И даже для тех, кто привык работать с Oracle или MSSQL привычно :)

Что ж, если при этом она ни в чем типа производительности не потеряла, то рад за Вас.
ASA блокировочник или версионник?
Надеюсь, что и Оракл так поступит. Но, боюсь, они заняты более глобальными новшествами.
24 окт 04, 21:18    [1057027]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
vadiminfo
ASCRUS

Хе хе - в ASA поступили красивее - сделали и триггеры BEFORE, AFTER FOR EACH ROW с NEW и OLD , и триггеры AFTER FOR EACH STATEMENT с Inserted и Deleted. Получилось и удобно и гибко. И даже для тех, кто привык работать с Oracle или MSSQL привычно :)

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

Производительности не потеряла. Наоборот как раз из за того, что она блокировочник - выиграла. Дело в том, что в ASA при реализации любой функциональности ее разработчики очень тщательно продумывают модель реализации, анализируя опыт других РСУБД и вводя и ориентируясь на особенности развития ASA. Например в ASA так же как и в Оракле в BEFORE триггерах можно изменять значения полей для вставляемых и изменяемых записей. Соотвествующе само собой проверки на NOT NULL, FOREIGN KEY, CHECK, UNIQUE и т.д. будут выполнены СУБД только после выполнения триггеров, что например развязывает руки разработчикам в некоторых деликатных ситуациях и в то же время не вынуждает их к использованию жесткой парадигмы всех изменений только через ХП. С другой стороны с учетом того, что BEFORE триггера выполняются прямо в процессе во время физического изменения таблицы и блокировании записей, то любой откат из такого триггера гарантирует остановку операции, что убирает лишние нагрузки по физической записи в БД и лог, потерю лишнего времени на откат транзакции и блокировку множества записей. Действительно исходя из здравого смысла - если я оператором UPDATE изменяю миллион записей и на первой же из них мой триггер решает, что операция недопустима - легче сделать откат этой записи, со снятием с нее блокировки, чем сначала проводить физические операции над миллионом записей с их блокировкой, а потом делать долгий откат. В этом плане лично я считаю у ASA действительно реализовано множество правильных с точки зрения архитектуры СУБД решений, с одной стороны не ограничивающих разработчиков, а с другой позволяющих этой СУБД быть действительно шустрой, маленькой, самоадминистрирующейся и с довольно умным саморазвивающимся оптимизатором. Правда вот в некоторых случаях его хрен обманешь даже корреным переписанием запроса с целью изменения плана запроса, благо если оптимизатор действительно не прав, достаточно написать к ним на форум и через пару месяцев получить исправление заявленных ошибок и неточностей в СУБД. С учетом того, что фактически только последняя 9-ая версия стала использоваться на проектах с миллионами записей, что дает оптимистические надежды на рост в области SMB-решений, то за год почти в каждом ежемесячном паке было выложено только для одного оптимизатора 5-10 расширений в области добавления и улучшения алгоритмов обработки информации. Появились различные виды алгоритмов hash-соединений, рекурсивных, OLAP (полный аналог Оракловских OVER ... PARTITION BY ...), даже видел аналог автоматического построения индекса, где маленькая таблица во времянку сортируется по нужным полям и проводиться соединение с большой, которую оптимизатор счел гораздо выгоднее отсканить по кластерному ключу, чем соединять ее по существующему индексу с маленькой табличкой. Так же радует ведение кэша наиболее удачных планов запросов и ХП физически в самой БД, что позволяет во время перезагрузки БД или сервера за считанные секунды не только снова включить его в работу, но и сразу эффективно начать обработку поступающих запросов без нового цикла анализа и выявления наиболее оптимальных планов запросов по текущему состоянию информации БД. Ну а со статистикой проблема решена просто и эффективно - после построения плана запроса и его выполнения оптимизатор передает данные эврестическому анализатору, который в фоновом режиме сравнивает план и факт, корректирует статистику по тем таблицам, где она уже устарела, оставляет оптимизатору запросов информацию по рекомендациям о соединениях, плюс занимается выявлением наиболее оптимальных планов запросов, составляя коллекцию планов с наиболее легкой стоимостью и в случае их частого успешного попадания, навязыванию оптимизатору запросов использование этих планов, где оптимизитор не строит более запросов, пока эврестический анализатор не увидит большого расхождения между планом и фактом (что произойдет при изменении информации) и снова не заставит оптимизатор заниматься построением планов запросов. Тут стоит отметить что в ASA нет понятия компиляции ХП и других обьектов с планами запросов с физическим сохранением в БД - это происходит динамически во время старта БД, что убирает необходимость в случаях изменения информации заниматься пересбором статистики и перекомпиляции ХП. С другой стороны сама компиляции ХП и других обьектов действительно занимает микросекунды, уж не знаю как они этого добились - решения Watcom-а вроде как всегда слыли не самыми медленными, но проблем со скоростью в области компиляции ХП или динамического SQL не наблюдается совсем, что дает так же дополнительные возможности разработчикам на базе динамического SQL.
24 окт 04, 22:10    [1057046]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
Alex.Czech
Guest
Ну как откуда 3 триггера... один BEFORE statement - список чистит, второй FOR EACH ROW - значения в список складывает, третий AFTER statement - собственно всю балалайку запускает в работу.

Зачем нужны inserted и updated...ну как зачем. В лог если нужно записывать изменения в базу вносимые, вы из триггера for each row это будете делать ? Оно хорошо, если записи по одной изменяют, а если когда как получится, то вот и проигрыш в производительности (гипотетически, повторюсь что не сравнивал).

Насчет "париться с курсорами" разработчику Оракл должно быть стыдно такие слова произносить вообще, я считаю :)
25 окт 04, 01:06    [1057101]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Alex.Czech

Ну как откуда 3 триггера... один BEFORE statement - список чистит, второй FOR EACH ROW - значения в список складывает, третий AFTER statement - собственно всю балалайку запускает в работу.

Ну Вы написали, что надо 3 триггера, чтобы получить. Триггер AFTER statement не получает а только использует, как использовал бы в MS SQL deleted и inserted. Триггер инициализации списка BEFORE может тоже не всегда нужен, например, если список сбрасывается во временные таблы, они могут очищаться при завершении транзакции. Ну, хорошо, посчитаем его. Два триггера нужно для получения.

Alex.Czech

Зачем нужны inserted и updated...ну как зачем.

Я спрашивал не за чем, а как часто, если есть NEW и OLD. Если бы была острая потребность, думаю, Оракл бы их все-таки поддерживал.
Alex.Czech

В лог если нужно записывать изменения в базу вносимые, вы из триггера for each row это будете делать ?

В зависимости от задачи. В общем случае в Ораклемогут использовать другие механизмы типа Streams.

Но если опять понадобиться инфа что на что заменили в этих журналах. Например, аудите. Что Вы будете делать? Создавать дополнительные уникальные спец колонки для соединений inserted и deleted?

Alex.Czech

Насчет "париться с курсорами" разработчику Оракл должно быть стыдно такие слова произносить вообще, я считаю :)

А что же вы не хотите три триггера вместо одного писать? Все лучше смотрится чем курсор для NEW и OLD. И что скрывается за этим курсором? Запрос? Ведь NEW и OLD нужны в триггере на уровне записи, который выполняется столько раз, сколько записей изменяется. Столько раз курсоры открывать и запросы выполнять? Да и если они часто нужны, то не замусорят ли эти курсоры - код? Ведь если список для inserted и deleted ассоциативный массив, то даже неявные курсоры не используются при их инициализации и получении. А кол-во открытых курсоров имеет значение для сервера в плане ресурсов.
Что каксается стыда для разработчика то, так можно устыдиться и писать на чем либо кроме ассемблера. Было и такое в истории - Настоящий программист пишет только на ассемблере:)
25 окт 04, 20:51    [1059669]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
автор
А что же вы не хотите три триггера вместо одного писать? Все лучше смотрится чем курсор для NEW и OLD. И что скрывается за этим курсором? Запрос? Ведь NEW и OLD нужны в триггере на уровне записи, который выполняется столько раз, сколько записей изменяется. Столько раз курсоры открывать и запросы выполнять? Да и если они часто нужны, то не замусорят ли эти курсоры - код? Ведь если список для inserted и deleted ассоциативный массив, то даже неявные курсоры не используются при их инициализации и получении. А кол-во открытых курсоров имеет значение для сервера в плане ресурсов.

Вообще то AFTER FOR EACH STATEMENT выполняется только один раз на все изменения, которые и содержаться в таблицах Inserted и Deleted. И если мне например после изменения информации в таблице необходимо пересчитать другую информацию в таблице, то в триггере AFTER UPDATE FOR EACH STATEMENT достаточно написать:
UPDATE Table1 t1
SET Value = Value + i.Value - d.Value
FROM Table1 t1
  INNER JOIN Inserted i ON i.id = t1.id
  INNER JOIN Deleted d ON d.id = t1.id;
и почему то у меня есть подозрение это сработает гораздо быстрее, чем если бы я на миллион записей навесил FOR EACH ROW и на каждую из миллиона записей выполнял UPDATE, Вам не кажется ?
25 окт 04, 21:45    [1059703]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
ASCRUS

и почему то у меня есть подозрение это сработает гораздо быстрее, чем если бы я на миллион записей навесил FOR EACH ROW и на каждую из миллиона записей выполнял UPDATE, Вам не кажется ?

Может я не совсем понял про какие Вы миллион UPDATE? После того как deleted и inserted сформированы, если они нужны, я могу использовать Ваш пример. (Хотя не совсем его понял) Т.е. до AFTER FOR EACH STATEMENT я их уже получил. Или Вы про само получение deleted и inserted? Это те два триггера BEFOR FOR EACH STATEMENT (инициализация) и BEFORE FOR EACH ROW. Я писал, что там может не быть вовсе неявных курсоров, в частности UPDATE. Там BEFORE FOR EACH ROW может просто записывать псевдозаписи в коллекцию ассоциативный массив - пременная PL/SQL (просто присвоения). Т.е. ни в БД. Инициализация при первом запуске вообще ничего не стоит - коллекция еще пустая. Поэтому там есть миллион присвоений (относительно примитивных записей в ОП). Ну, как например, соотносятся записи в коллекцию по сравнению с записями измнений собственно данных в блок БД (с которыми связаны более сложные алгоритмы, и часть блоков вообще может еще не быть в ОП)? Не уверен, но мне кажется, что запись в коллекцию добавит не много процентов. Ну и от объема памяти тоже кое-что зависит. А триггер AFTER FOR EACH STATEMENT использует эту коллекцию как deleted и inserted. Но вместо них можно получить, например, updated, где видно что на что заменено.
Не сомневаюсь, что можно придумать ситуации где deleted и inserted очень бы подошли. Возможно, была бы еще полезна структура updated, где видно что на что заменено. Да и наверное еще много чего.
Я говорил, что не против если бы были deleted и inserted, но мне пока все еще кажутся более важными псевдозаписи NEW и OLD.
26 окт 04, 00:46    [1059784]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Мой пример означает, что когда я делаю:
UPDATE Table2
SET Value = Value - 100;
где в таблице Table2 обновляется миллион записей, после их обновления будет один раз вызван триггер AFTER UPDATE FOR EACH STATEMENT, который произведет обновление в аггрегирующей таблице Table1, вычитая с нее старые суммы Table2 и прибавляя новые. В своем примере я не очень вижу какие то курсоры. И мне не надо делать ручками какие то коллекции, заполнять их на AFTER FOR EACH ROW и обрабатывать потом на AFTER FOR EACH STATEMENT.

автор
Возможно, была бы еще полезна структура updated, где видно что на что заменено. Да и наверное еще много чего.

Соединение по первичному ключу Inserted и Deleted всегда даст понятие, что на что изменилось. Из чего следует вывод, что данная конкепция отрицает изменение первичного ключа и поощряет использование ИК вместо ЕК (с чем я полностью согласен).

автор
Я говорил, что не против если бы были deleted и inserted, но мне пока все еще кажутся более важными псевдозаписи NEW и OLD.

Ну мне в этом плане легче, так как есть и то и то :) Остается это только с умом использовать в различных ситуациях :)
26 окт 04, 06:58    [1059884]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
ASCRUS
Хе хе - в ASA поступили красивее - сделали и триггеры BEFORE, AFTER FOR EACH ROW с NEW и OLD , и триггеры AFTER FOR EACH STATEMENT с Inserted и Deleted. Получилось и удобно и гибко. И даже для тех, кто привык работать с Oracle или MSSQL привычно :)


В DB2 все это было с 5 версии.
26 окт 04, 10:09    [1060245]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
ASCRUS
Мой пример означает, что когда я делаю:
UPDATE Table2
SET Value = Value - 100;
где в таблице Table2 обновляется миллион записей, после их обновления будет один раз вызван триггер AFTER UPDATE FOR EACH STATEMENT, который произведет обновление в аггрегирующей таблице Table1, вычитая с нее старые суммы Table2 и прибавляя новые. В своем примере я не очень вижу какие то курсоры. И мне не надо делать ручками какие то коллекции, заполнять их на AFTER FOR EACH ROW и обрабатывать потом на AFTER FOR EACH STATEMENT.

автор
Возможно, была бы еще полезна структура updated, где видно что на что заменено. Да и наверное еще много чего.

Соединение по первичному ключу Inserted и Deleted всегда даст понятие, что на что изменилось. Из чего следует вывод, что данная конкепция отрицает изменение первичного ключа и поощряет использование ИК вместо ЕК (с чем я полностью согласен).

автор
Я говорил, что не против если бы были deleted и inserted, но мне пока все еще кажутся более важными псевдозаписи NEW и OLD.

Ну мне в этом плане легче, так как есть и то и то :) Остается это только с умом использовать в различных ситуациях :)


А как быть, если на таблицу навешать триггеры сразу и FOR EACH STATEMENT и FOR EACH ROW? :)
26 окт 04, 10:14    [1060258]     Ответить | Цитировать Сообщить модератору
 Re: А зачем нужен этот монстр....... MS SQL?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
gardenman
ASCRUS
Хе хе - в ASA поступили красивее - сделали и триггеры BEFORE, AFTER FOR EACH ROW с NEW и OLD , и триггеры AFTER FOR EACH STATEMENT с Inserted и Deleted. Получилось и удобно и гибко. И даже для тех, кто привык работать с Oracle или MSSQL привычно :)


В DB2 все это было с 5 версии.

И в ASA с 4 версии еще под ДОС (1994 год) :)

автор
А как быть, если на таблицу навешать триггеры сразу и FOR EACH STATEMENT и FOR EACH ROW? :)

Как и полагается - для каждой записи в зависимости от порядкового номера будут срабатывать триггера FOR EACH ROW и в конце сработают по порядковым номерам триггера FOR EACH STATEMENT.
26 окт 04, 10:20    [1060282]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 5 6 7 8 9 [10] 11 12 13 14 .. 17   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить