![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
PL/SQL Цикл по полям.
Курдль © (2008-08-22 17:37:00)Коллеги!
Возможно ли в триггере организовать цикл по полям таблицы?
Это нужно для замысловатого журналирования написать триггера почти на все таблицы, чтобы вычислять изменившиеся поля и писать их в логи. На SQL.ru искал решения - но нашел только такие же вопросы без ответов...
Игорь Шевченко (2008-09-05 11:06:00) [1]
> Возможно ли в триггере организовать цикл по полям таблицы?
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:59412348055
Германн (2008-08-28 01:42:00) [2]
> Курдль (27.08.08 12:39) [33]
>
>
> > Германн © (27.08.08 01:33) [30]
> > Вот именно такие аргументы я и "записываю". Тем более
> если
> > эти аргументы высказаны в подобной дискуссии.
>
>
> Тут Вам посоветовать ничего нельзя, не зная, что за приложение
> Вы разрабатываете.
> А вдруг какй-нибудь OLAP-продвинутый построитель отчетов?
> Тогда может и надо его под разные базы затачивать. Или,
> тем более, - среду ETL. Так ей сам Бог велел!..
>
Я в последнее время ничего сам не разрабатываю. Ну в отношении программ для РС. Но я записываю подобные аргументы для представления их тем, кто хочет создать ПО, которое записывает в БД данные (и показывает их), причем "независимо" от провайдера и типа БД.
Курдль (2008-08-27 12:39:00) [3]
> Германн © (27.08.08 01:33) [30]
> Вот именно такие аргументы я и "записываю". Тем более если
> эти аргументы высказаны в подобной дискуссии.
Тут Вам посоветовать ничего нельзя, не зная, что за приложение Вы разрабатываете.
А вдруг какй-нибудь OLAP-продвинутый построитель отчетов? Тогда может и надо его под разные базы затачивать. Или, тем более, - среду ETL. Так ей сам Бог велел!..
Германн (2008-08-27 02:19:00) [4]Удалено модератором
Petr V. Abramov (2008-08-27 02:11:00) [5]Удалено модератором
Германн (2008-08-27 01:33:00) [6]
> Курдль (26.08.08 09:23) [20]
>
> А что, собственно, надо оспорить или защитить?
...
> Просто не надо
> питать иллюзий, что можно создать коробочную версию системы,
> чтобы, типа, при установке она спросила: "На Вашем ПК обнаружены
> следующие 3 СУБД: ... Какую из них выбрать?".
>
Вот именно такие аргументы я и "записываю". Тем более если эти аргументы высказаны в подобной дискуссии.
Petr V. Abramov (2008-08-27 01:30:00) [7]опять же:
поле в таблице рпибавили/убавили.
софт д.б. чтоб триггеры по крайней мере valid остались.
Petr V. Abramov (2008-08-27 01:26:00) [8]Удалено модератором
Sergey Masloff (2008-08-26 22:51:00) [9]Действительно на DATABASE OPTIONS DETAILS 18.09 кто еще идет? Я пока точно не знаю но с вероятностью 50% пойду
Sergey Masloff (2008-08-26 22:50:00) [10]Petr V. Abramov © (26.08.08 12:19) [24]
>это уже все написано в логах. есть инструмент, чтоб логи разобрать. >Нафига городить тыщу дурацких триггеров и тормозить базу?
Торможения нет проверялось...
А логи... если просмотр истории ситуация частая то не очень удобно в логи лазать каждый раз. Вобщем все от ситуации зависит в одном на логах нормально в другом и триггер сгенеренный не помешает.
Курдль (2008-08-26 13:31:00) [11]
> Petr V. Abramov © (26.08.08 12:19) [24]
>
>
> > И че ? Есть заказчики, которые желают знать, кто именно
> > и что изменил. Их полное и неотъемлемое право
>
> это уже все написано в логах. есть инструмент, чтоб логи
> разобрать. Нафига городить тыщу дурацких триггеров и тормозить
> базу?
Конгениально, коллега!
Только надо знать особенности организационной структуры и информационной безопасности в конкретной компании!
Если логи доступны DB-админам, находящимся в другом конце города и вовсе не напрашивающимся (мягко говоря) на доп. работу?
А "торможение триггерами" могу себе представить только в хранилищах данных, где критичны периоды массовой загрузки информации. В OLTP-системах такой триггер отработает незаметно.
Petr V. Abramov (2008-08-26 12:19:00) [12]
> И че ? Есть заказчики, которые желают знать, кто именно
> и что изменил. Их полное и неотъемлемое право
это уже все написано в логах. есть инструмент, чтоб логи разобрать. Нафига городить тыщу дурацких триггеров и тормозить базу?
Игорь Шевченко (2008-08-26 11:47:00) [13]Курдль (26.08.08 11:28) [22]
> Приведи пример (не касающийся оговоренного триггера).
Том Кайт, "Эффективное проектирование приложений Oracle", стр. 17
> 99% запросов можно исполнить на классическом ANSI.
Исполнить можно. Результаты могут отличаться
> Матерые ораклисты с презрением смотрят на мой ораклевый
> код "...left outer join ... on ...". Однако, он в оракле
> работает ничуть не хуже, чем "(+) = ".
Ну это же просто синонимы...
Курдль (2008-08-26 11:28:00) [14]
> Из этого, увы, следует, что для того, чтобы разрабатывать
> надежные приложения не зависящие от СУБД или делать "кастомизацию"
> под разные СУБД необходимо иметь в команде разработчиков
> людей, которые ориентируются во внутренностях конкретной
> СУБД, как поп в Ветхом законе.
Приведи пример (не касающийся оговоренного триггера).
Матерые ораклисты с презрением смотрят на мой ораклевый код "...left outer join ... on ...". Однако, он в оракле работает ничуть не хуже, чем "(+) = ". (Кстати, СУБД оракл иногда ругается на нее, как на устаревшую).
Где должна проявиться особо узкая специализация разработчиков? 99% запросов можно исполнить на классическом ANSI.
Игорь Шевченко (2008-08-26 09:42:00) [15]Курдль (26.08.08 09:23) [20]
> Просто если для кастомизации под конкретную СУБД потребуется
> 10% от проектного ресурса - это хороший результат. Но достичь
> его будет немыслимо, если серверную логику повесить на СУБД.
>
Да, конечно, достичь такого результата немыслимо не только, если повесить логику на СУБД. СУБД, они не только имеют разные средства для создания серверной логики, они еще и ведут себя по-разному в отношениях с клиентами.
Опять же, процитирую Кайта:
"Фундаментальные модели согласованности и управления параллелизмом разных баз данных радикально отличаются друг от друга. Последовательность операторов в одной базе данных может, а иногда и будет приводить к результату, отличному от результатов в другой базе данных".
Из этого, увы, следует, что для того, чтобы разрабатывать надежные приложения не зависящие от СУБД или делать "кастомизацию" под разные СУБД необходимо иметь в команде разработчиков людей, которые ориентируются во внутренностях конкретной СУБД, как поп в Ветхом законе.
Весьма вероятно, что твой вопрос в какой-то из СУБД (про поля в триггере) решается легко и просто, а вот в Oracle, увы, не решается, да оно и не надо :)
Курдль (2008-08-26 09:23:00) [16]
> Германн © (26.08.08 02:01) [19]
>
> Я серьёзно. Я действительно "записываю".
> Для меня это весомый аргумент в разговоре с т.н. "техническим"
> "директором".
> И не случайно я поставил кавычки два раза.
А что, собственно, надо оспорить или защитить?
Я о "мультибазовых" проектах не упоминал. Но я не против них. Более того, я участвовал в одном таком. Просто не надо питать иллюзий, что можно создать коробочную версию системы, чтобы, типа, при установке она спросила: "На Вашем ПК обнаружены следующие 3 СУБД: ... Какую из них выбрать?".
Просто если для кастомизации под конкретную СУБД потребуется 10% от проектного ресурса - это хороший результат. Но достичь его будет немыслимо, если серверную логику повесить на СУБД.
Германн (2008-08-26 02:01:00) [17]Я серьёзно. Я действительно "записываю".
Для меня это весомый аргумент в разговоре с т.н. "техническим" "директором".
И не случайно я поставил кавычки два раза.
Германн (2008-08-26 01:49:00) [18]Эээ.
Вы давайте продолжать рассуждения о
> Трудно поддерживать повторяемость в проектах под разные
> СУБД.
и
> Собственно, разрабатывать относительно большой проект под
> разные СУБД особо большого смысла не имеет - получится "плохой
> под разные СУБД" проект, слово "плохой" можно смело заменить
> на "неоптимальный".
>
О пиве и о местонахождении (географии административных округов) можно "потрепаться" в соответствующей конференции. :)
"По-ммедленнее, пожалуйста. Я записсываю."
(с) Шурик
Игорь Шевченко (2008-08-25 17:40:00) [19]
> Да леГко! :) Только Савелия не предлагать. Я туда в разумное
> время не доеду.
> Мой ареал - между ЦАО и ВАО.
Э...пораньше бы :) Сдается мне, что на ближайшее время у меня будет строго САО.
Что касается примеров - оно все конструкторы, и ETL Informatica Power Center и "oracle Data Integrator и тем более Oracle Warehouse Builder" - то есть, дается полуфабрикат и пара дюжин напильников, которыми этот полуфабрикат доводится до приемлемого в использовании продукта.
Может, оно и неплохо, может, и очень неплохо, но я веду речь о готовых продуктах, за которые конечный заказчик денег платит, разработкой каковых я, собственно, и занимаюсь. И делать в этом случае конструктор, прикладывая к нему кучу напильников, мне не слишком улыбается, еще и по той причине, что продукт довольно специализирован, знаний по предметке накоплено достаточно, узкие места и способы их обхода примерно известны. Так что заказчику проще приобрести оракл :)
Курдль (2008-08-25 17:24:00) [20]
> Игорь Шевченко © (25.08.08 16:45) [15]
> Будет желание и возможность - можешь и со мной за пивом поспорить.
Да леГко! :) Только Савелия не предлагать. Я туда в разумное время не доеду.
Мой ареал - между ЦАО и ВАО.
Кстати, я в своих аргументах против серверной логики о "мультибазовых" проектах не упоминал.
Я говорил про технологическую вооруженность софтверной компании.
Кайт - мужчинка уважаемый. Но он, кажись, и говорил, что "при проектировании БД самый худший враг - догматизм".
Про авторитетность зерцал IT-шных наук. Я с интервалом в год имел удовольствие присутствовать на семинарах с участием 2-х главных светил в области хранилищ данных - Р.Кимбалла и Б.Инмона (который первый и ввел в обиход словосочетание ХД). Так у них чуть ли не диаметрально противоположные архитектурные подходы. Однако - у обоих десятки внедренных с успехом проектов уровня "Пентагон" за плечами.
И еще пример из области ХД.
Признанный лидер в области нитеграции - Informatica создала средство ETL Informatica Power Center, который служит для извлечения данных из БД-источников, их трансформации и загрузки в БД-приемники. Так вот - он работает на собственном сервере приложений и выполняет коды специализированных программ.
А oracle Data Integrator и тем более Oracle Warehouse Builder, нацеленные на создание скриптов и процедур для исполнения СУБД, далеко отстают от Informatica.