gardenmanНужно рассматривать триггеры в рамках единицы работы... а то как бы чего не вышло...))
Не очень понял - чего именно может выйти ? Как спроектируете логику триггеров, так они работать и будут :) Однако думаю все могут согласиться, чем больше у разработчика функциональных возможностей, тем больше у него развязаны руки более правильно спроектировать ту или иную логику работы. Соотвествующе чем меньше возможностей, тем больше решения иногда напоминают садо-мазо с тройным сальто через собственную голову и риском потом об этом пожалеть. Естественно в таких случаях лучше искать другие пути решения задачи, чем пытаться навязать продукту сделать то, что он не умеет, не предназначен или делает это не сильно хорошо. Это легко прослеживается при переходе специалистов с одной платформы на другую (и без разницы какую именно - с Access на Delphi, с MSSQL на Oracle, с Delphi на PowerBuilder и т.д.) - частенько они пытаются навязать привычную для них логику изучаемому продукту, для которого она оказывется противопоказанной. Отсюда все и беды и рассуждения, что вот типа MSSQL плох, а Оракл хорош, потому что в Оракле это есть, а там нет и наоборот соотвествующе :)

авторЕсли делать update миллиона записей, то может либо лог кончиться, либо нарваться на ограничение количества блокировок.
А вот это от реализации сервера и зависит. Где то можно нарваться на ограничения, а где то нет :)

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

Так что, к сожалению, простого выхода здесь нет. Приходится помнить, что можешь ошибиться и в том, и в другом случае.
Угу, именно поэтому я взял себе за правило хорошего тона при освоении другого продукта сначала изучать его базовые основы, не сравнивая с тем, что я уже знаю и на чем работал, и только после того, как я увидел его основные черты, тогда начинать сравнение с тем, что я уже хорошо знаю и на найденных различиях строить свое мнение о нем и выявлять наиболее удачные принципы работы с ним. Метод себя хорошо зарекомендовал - например годик назад изучая PowerBuilder, я честно прочитал по нему базовые книги, не обращая внимание на то, что с точки зрения той же Java или Delphi он напоминал неуклюжий утюг и не пытаясь сразу по ходу изучения все автоматизировать, налепить своих классов, подстраивающих его в привычную форму работы (хотя руки и чесались). Сейчас как результат - как оказалось в PB, если смотреть под другим углом, просто прекрасная концепция разделения функций интерфейса через ООП и функций работы с бизнес-логикой и визуальными отображениями через DataWindow. Любые вещи малым кол-вом кода реализуются просто на ура по сравнению с той же Delphi, возможности интрепретируемого языка DataWindow Expression для построения форм, гридов, графиков и отчетов просто шикарные и позволяют делать не только клиентские приложения, но и целые платформы с автоматическим построением визуальных представлений по обьектам БД. Думаю говорить не стоит, что было бы, если бы я попытался на нем программировать в привычной колее - такой результат частенько отслеживается гневными воплями на многих дельфийских форумах народа, которому приходилось встречаться с PowerBuilder :) То же самое можно полностью сказать о любой СУБД, можно между собой сравнить MSSQL и ASE именно как СУБД, но даже ASA с ними сравнивать уже не корректно, так как у нее уже совершенно другая архитектура и соотвествующе другие возможности и другие правила удачного использования. Я в таком случае предпочитаю производить сравнение в ценовом эквиваленте - затраты на закупку СУБД, разработку, сопровождение и стоимость владения, естественно при условии соблюдения выбранной СУБД всех условий по постановке задачи.

авторASCRUS наверно намекал на то, что в ASA и MSSQL лог может расти автоматически. Но ведь все равно диск когда-нить кончится.
А что - миллион записей так уж много весит в эквиваленте дискового пространства ?

авторЕсли Update происходит в рамках одной транзакции - запросто - на любом серваке. Если по какой-то причине блокировка на уровне строки или страницы не трансформировалась в блокировку на уровне таблицы - то прийти в итоге к ROLLBACK - элементарно.Особенно когда имеются триггеры. Ведь тогда наверняка блокировки вешаются не на одну таблицу. Эмулировать такое поведение - раз плюнуть. Ну, а нехватка лога - ребята, неужели у вас ни у кого не было log out of space? Не верю... Также не поверю что никогда в жизни при получении декартова произведения в криво написанном запросе вы в tempdb не получали out of space.
Нет у нас понятия блокировки на уровне страницы и эксколации блокировок. Если ASA что то такое и делает, то никак и никем это не заметно. Это только в MSSQL сделали огромный механизм борьбы с блокировками, который по моему больше мешает, чем помогает. Может быть им вместо него нужно было бы по другому реализовать саму архитектуру блокировок ? И не было у меня проблем с нехваткой лога, на ASA не крутяться террабайтные БД, это СУБД для SMB решений (рабочих групп), сотня гигов - это уже нонсенс для такого решения, а вроде как уже давно на серверах винты не по 10 гб стоят :) И так же у нас нет tempdb, у ASA все динамично, в том числе и временные файлы, которые создаются и удаляются автоматически во время запуска и остановки сервера, что и как хранить временно - это чисто проблемы ASA, что и правильно для СУБД, которая развивается на концепциях интеллектуальной СУБД с нулевым администрированием. Причем это не означает, что она настолько умна, что сама все сделает. Это означает, что для девелопера в ее возможностях есть необходимый запас функционала, позволяющий в момент разработки БД предусмотреть различные ситуации и прописать модели поведения - от оптимизации запросов до разруливания конфликтов репликаций или системных ошибок.

vadiminfoТочнее данная конкепция не предполагает изменение первичного ключа. Однако, это концепция реализации, а вопрос изменения первичного ключа - вопрос модели данных БД. Т.е. у нас реализация накладывает дополнительные ограничение на модель данных? Причем на существенный вопрос идентификации.
Думаю не стоит развивать спор на тему ЕК vs ИК. Даже на форуме MSSQL он стал напоминать лестницу. Могу сказать только одно - в моих базах данных первичные ключи не изменяются и никаких проблем в связи с этим я ни разу не наблюдал.

vadiminfoА если NEW и OLD используются для изменения значений в той же табле, Вы по прежнему будете Inserted и Deleted использовать? Делать ручками какие-то запросы.
Есть такое понятие - каскадные триггеры. Если Вы в AFTER FOR EACH STATEMENT триггере напишите UPDATE "СноваЭтаТаблица", то на этот UPDATE будут заново вызваны все триггеры и для них уже будут свои Inserted и Deleted. И естественно у каждой СУБД будут свои механизмы управления каскадностью.

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

Я тут кстати ради интереса на ASA взял табличку с 1,5 миллионов записей, накатал на нее триггер AFTER UPDATE FOR EACH STATEMENT, который в родительской табличке с 4,5 миллионов записей выполнял пересчет суммирующего поля:
потом написал:
и оттарабанив 3 минуты на моей машине с загрузом процессора где процентов на 30 в среднем запрос был выполнен успешно вместе с триггером. Нехватки пространства для лога (он вообще для этой тестовой БД установлен с опцией сброса после завершения транзакции), нехватки места под временные файлы, затыкания блокировок или еще какой гадости замечено не было, причем памяти серверу было отведено на винде всего 400 метров, что в принципе под 11 гиговую БД и эти широкие таблички даже маловато будет.

авторМеня скорее удивляет "особая роль" первичного ключа, который ничем особенным не выделяется. То есть, насколько я видел, в теоретических выкладках любят говорить "есть первичный ключ", подразумевая "есть хоть какой-нибудь уникальный ключ".
Полностью согласен с этим. В ASA например FOREIGN KEY можно вешать не только на первичный, но и любой unique constraint. В данном случае первичный ключ обязательно нужен для оператора
который насколько я понимаю является аналогом Оракловского MERGE.

авторunique constraint - поле/комбинация полей, соответствующих ограничению уникальности, но не являющихся ключом (допускающее комбинацию "все равны null").
А вот тут у нас как раз UNIQUE CONSTRAINT не могут делаться на NULL поля (возможно как раз из за возможности FOREIGN KEY по ним). Для обеспечения уникальности по NULL полям нужно делать UNIQUE INDEX.