Ну во-первых подход древний(кажется еще Кайт его описывал и уже тогда предлагал вариант получше — с mview log+fast refresh)
Предложеный мною вариант не претендует на новизну. Скорее это пример практически реализованного на двух десятках серверов решения прошедшего годовую обкатку под нагрузкой OLTP до 300 коннектов и пока не приведшего к ужасам описаными Вами ниже.
Однако должен уточнить некоторые условия эксплуатации. Данный констрейнт по сути эмулирует для пакетного режима ввода интерактивный режим ввода через форму на клиенте. Форма толстого клиента именно так и работает — бизнеслогика зашитая в ней обеспечивает формирование на полях корректного набора данных и лиш потом позволяет запостить и закомитить данные на сервере. Реальная реализация констрейнта динамически включена только для сеансов пользователей под которыми работают внешние программные шлюзы (функция пакета chk_on). Для интерактивных сеансов толстого клиента триггера и матвьюха отдыхают а конкуренции на матвьюхе отсутствует.
Наверно в основном посте я сосредоточился на описании инструмента опустив технологию применения — похоже напрасно. Инструмент не претендует на всеобщую универсальность но свою задачу решает. их коммиты будут ждать друг друга из-за блокировок на MVIEW — если включить констрейнт для всех сеансов — да, полностью согласен. Но поправимо. Поскольку блокировки ставятся построчно доработаем так, что бы каждый сеанс работал только со своими строками. Добавим в emp_chk и матвью два поля идентификаторов сеанса (sid/serial). Соответсвенно протянуть обработку этих полей во фразе where через все модули. Спасибо за идею ) И кстати, подход Кайта в вашем примере Извините. Смысл был в том чтоб описать архитектуру решения на простом примере. Вроде есть самосвал в который грузят ведро грунта для примера. В результате половина постов смотрят не на самосвал а на ведро грута и предлагают переделать самосвал в велосипед с прицепом потому как для ведра грунта достаточно велосипеда (извините за безобразное упрощенчество). Продолжаю повторять что с моей точки зрения решение легко масштабируется тк исходники триггеров 2х типов по сути являются шаблонами для установки которых на любую таблицу необходимы минимальные правки исходника. И если Вы таки встречали сложную бизнеслогику (см выше )) на форме то согласитесь что 200 строк из 4х шаблонов кода как плата за перенос ее из клиента на сервер не высока.
Всетаки задача предложеного иструмента конкретна — допускать к фиксации только прошедшие бизнеслогику данные. Задача доопределять данные инициируя дополнительные DML не стоияла.
Похоже INSTEAD OF триггера работают по каждому DML по полям вьюхи — тогда возражаю. Функционал должен работать только по конечному набору данных.
Любой функционал приводит к расходам. Если функционал лишний — расходы тоже излишние.
Общие замечания.
Возраст реального комплекса полтора десятка лет — поэтому речь идет не столько о разработке космических кораблей сколько о ремонте и поддержке любимых велосипедов. Данные примера на которые накручен функционал в статье так-же соотносятся с реальными как соотносятся морская свинка и море )
Теперь серьезнее.
Предложение вынести бизнеслогику я бы сформулировал иначе. Смысл не в том в каком месте физически реализована бизнеслогика, а в том что бизнеслогика и функционал системной поддержи должны реализовываться в отдельных модулях. Эта попытка сделана (наверно несовременно) — вся бизнеслогика реализована в отдельной функции. Исполнитель поддерживающий эту функцию имеет очень поверхностные представления о системном слое вызова и отлаживает ее простым вызовом передав идентификатор экзэмляра проверяемой сущности. При этом текст с парой операторов в триггерах (по сравнению с текстом функции контроля) словом логика даже называть неудобно.
О массовых многострочных операциях.
При одном коммите "на нескольких миллионах строк" по десятку таблиц серверу с OLTP нагрузкой будет весело и без констрейнта.
Но говорят дбашникам никогда не надоедает смотреть на воду, огонь, кокуренцию на блокировках, и рост сегментов отката )
А когда надоедает они отключают констрейнт функцией var_chk.chk_on, которая в примере реализована как заглушка.
2teleavtomatika Предкомпилированый код PLSQL хранящийся на сервере вроде не самое плохое решение по производительности. Ошибаюсь? Серверов БД с… тысяч сток кода ну очень много — достаточно заглянуть в схемы SYSTEM и SYS.
2Ariant. Вас просто не понял. Предложите Ваше решение контроля информации одной строки по содержанию другой — выберем лучшее).
2sassy. Матвью не самоцель — инструмент. Цель-инициировать процесс котроля только по коммиту.
По VIEW и INSTEAD OF триггера — спасибо, посмотрю подумаю.
Извините повторюсь. Решение не идеально но оно реально работает.
Предложеный мною вариант не претендует на новизну. Скорее это пример практически реализованного на двух десятках серверов решения прошедшего годовую обкатку под нагрузкой OLTP до 300 коннектов и пока не приведшего к ужасам описаными Вами ниже.
Однако должен уточнить некоторые условия эксплуатации. Данный констрейнт по сути эмулирует для пакетного режима ввода интерактивный режим ввода через форму на клиенте. Форма толстого клиента именно так и работает — бизнеслогика зашитая в ней обеспечивает формирование на полях корректного набора данных и лиш потом позволяет запостить и закомитить данные на сервере. Реальная реализация констрейнта динамически включена только для сеансов пользователей под которыми работают внешние программные шлюзы (функция пакета chk_on). Для интерактивных сеансов толстого клиента триггера и матвьюха отдыхают а конкуренции на матвьюхе отсутствует.
Наверно в основном посте я сосредоточился на описании инструмента опустив технологию применения — похоже напрасно. Инструмент не претендует на всеобщую универсальность но свою задачу решает.
их коммиты будут ждать друг друга из-за блокировок на MVIEW — если включить констрейнт для всех сеансов — да, полностью согласен. Но поправимо. Поскольку блокировки ставятся построчно доработаем так, что бы каждый сеанс работал только со своими строками. Добавим в emp_chk и матвью два поля идентификаторов сеанса (sid/serial). Соответсвенно протянуть обработку этих полей во фразе where через все модули. Спасибо за идею )
И кстати, подход Кайта в вашем примере Извините. Смысл был в том чтоб описать архитектуру решения на простом примере. Вроде есть самосвал в который грузят ведро грунта для примера. В результате половина постов смотрят не на самосвал а на ведро грута и предлагают переделать самосвал в велосипед с прицепом потому как для ведра грунта достаточно велосипеда (извините за безобразное упрощенчество). Продолжаю повторять что с моей точки зрения решение легко масштабируется тк исходники триггеров 2х типов по сути являются шаблонами для установки которых на любую таблицу необходимы минимальные правки исходника. И если Вы таки встречали сложную бизнеслогику (см выше )) на форме то согласитесь что 200 строк из 4х шаблонов кода как плата за перенос ее из клиента на сервер не высока.
Похоже INSTEAD OF триггера работают по каждому DML по полям вьюхи — тогда возражаю. Функционал должен работать только по конечному набору данных.
Любой функционал приводит к расходам. Если функционал лишний — расходы тоже излишние.
Возраст реального комплекса полтора десятка лет — поэтому речь идет не столько о разработке космических кораблей сколько о ремонте и поддержке любимых велосипедов. Данные примера на которые накручен функционал в статье так-же соотносятся с реальными как соотносятся морская свинка и море )
Теперь серьезнее.
Предложение вынести бизнеслогику я бы сформулировал иначе. Смысл не в том в каком месте физически реализована бизнеслогика, а в том что бизнеслогика и функционал системной поддержи должны реализовываться в отдельных модулях. Эта попытка сделана (наверно несовременно) — вся бизнеслогика реализована в отдельной функции. Исполнитель поддерживающий эту функцию имеет очень поверхностные представления о системном слое вызова и отлаживает ее простым вызовом передав идентификатор экзэмляра проверяемой сущности. При этом текст с парой операторов в триггерах (по сравнению с текстом функции контроля) словом логика даже называть неудобно.
О массовых многострочных операциях.
При одном коммите "на нескольких миллионах строк" по десятку таблиц серверу с OLTP нагрузкой будет весело и без констрейнта.
Но говорят дбашникам никогда не надоедает смотреть на воду, огонь, кокуренцию на блокировках, и рост сегментов отката )
А когда надоедает они отключают констрейнт функцией var_chk.chk_on, которая в примере реализована как заглушка.
2teleavtomatika Предкомпилированый код PLSQL хранящийся на сервере вроде не самое плохое решение по производительности. Ошибаюсь? Серверов БД с… тысяч сток кода ну очень много — достаточно заглянуть в схемы SYSTEM и SYS.
2Ariant. Вас просто не понял. Предложите Ваше решение контроля информации одной строки по содержанию другой — выберем лучшее).
2sassy. Матвью не самоцель — инструмент. Цель-инициировать процесс котроля только по коммиту.
По VIEW и INSTEAD OF триггера — спасибо, посмотрю подумаю.
Извините повторюсь. Решение не идеально но оно реально работает.