> Германн ©   (26.08.08 02:01) [19]
>
> Я серьёзно. Я действительно "записываю".
> Для меня это весомый аргумент в разговоре с т.н. "техническим"
> "директором".
> И не случайно я поставил кавычки два раза.


А что, собственно, надо оспорить или защитить?
Я о "мультибазовых" проектах не упоминал. Но я не против них. Более того, я участвовал в одном таком. Просто не надо питать иллюзий, что можно создать коробочную версию системы, чтобы, типа, при установке она спросила: "На Вашем ПК обнаружены следующие 3 СУБД: ...  Какую из них выбрать?".
Просто если для кастомизации под конкретную СУБД потребуется 10% от проектного ресурса - это хороший результат. Но достичь его будет немыслимо, если серверную логику повесить на СУБД.

Курдль   (26.08.08 09:23) [20]


> Просто если для кастомизации под конкретную СУБД потребуется
> 10% от проектного ресурса - это хороший результат. Но достичь
> его будет немыслимо, если серверную логику повесить на СУБД.
>


Да, конечно, достичь такого результата немыслимо не только, если повесить логику на СУБД. СУБД, они не только имеют разные средства для создания серверной логики, они еще и ведут себя по-разному в отношениях с клиентами.

Опять же, процитирую Кайта:
"Фундаментальные модели согласованности и управления параллелизмом разных баз данных радикально отличаются друг от друга. Последовательность операторов в одной базе данных может, а иногда и будет приводить к результату, отличному от результатов в другой базе данных".

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

Весьма вероятно, что твой вопрос в какой-то из СУБД (про поля в триггере) решается легко и просто, а вот в Oracle, увы, не решается, да оно и не надо :)

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


Приведи пример (не касающийся оговоренного триггера).
Матерые ораклисты с презрением смотрят на мой ораклевый код "...left outer join ... on ...". Однако, он в оракле работает ничуть не хуже, чем "(+) = ". (Кстати, СУБД оракл иногда ругается на нее, как на устаревшую).
Где должна проявиться особо узкая специализация разработчиков? 99% запросов можно исполнить на классическом ANSI.

Курдль   (26.08.08 11:28) [22]


> Приведи пример (не касающийся оговоренного триггера).


Том Кайт, "Эффективное проектирование приложений Oracle", стр. 17


> 99% запросов можно исполнить на классическом ANSI.


Исполнить можно. Результаты могут отличаться


> Матерые ораклисты с презрением смотрят на мой ораклевый
> код "...left outer join ... on ...". Однако, он в оракле
> работает ничуть не хуже, чем "(+) = ".


Ну это же просто синонимы...

> И че ? Есть заказчики, которые желают знать, кто именно
> и что изменил. Их полное и неотъемлемое право

это уже все написано в логах. есть инструмент, чтоб логи разобрать. Нафига городить тыщу дурацких триггеров и тормозить базу?

> Petr V. Abramov ©   (26.08.08 12:19) [24]
>
>
> > И че ? Есть заказчики, которые желают знать, кто именно
> > и что изменил. Их полное и неотъемлемое право
>
> это уже все написано в логах. есть инструмент, чтоб логи
> разобрать. Нафига городить тыщу дурацких триггеров и тормозить
> базу?


Конгениально, коллега!

Только надо знать особенности организационной структуры и информационной безопасности в конкретной компании!
Если логи доступны DB-админам, находящимся в другом конце города и вовсе не напрашивающимся (мягко говоря) на доп. работу?

А "торможение триггерами" могу себе представить только в хранилищах данных, где критичны периоды массовой загрузки информации. В OLTP-системах такой триггер отработает незаметно.

Petr V. Abramov ©   (26.08.08 12:19) [24]

>это уже все написано в логах. есть инструмент, чтоб логи разобрать. >Нафига городить тыщу дурацких триггеров и тормозить базу?
Торможения нет проверялось...

А логи... если просмотр истории ситуация частая то не очень удобно в логи лазать каждый раз. Вобщем все от ситуации зависит в одном на логах нормально в другом и триггер сгенеренный не помешает.

Действительно на DATABASE OPTIONS DETAILS 18.09 кто еще идет? Я пока точно не знаю но с вероятностью 50% пойду

Удалено модератором

опять же:
поле в таблице рпибавили/убавили.
софт д.б. чтоб триггеры по крайней мере valid остались.

> Курдль   (26.08.08 09:23) [20]
>
> А что, собственно, надо оспорить или защитить?
...
> Просто не надо
> питать иллюзий, что можно создать коробочную версию системы,
>  чтобы, типа, при установке она спросила: "На Вашем ПК обнаружены
> следующие 3 СУБД: ...  Какую из них выбрать?".
>

Вот именно такие аргументы я и "записываю". Тем более если эти аргументы высказаны в подобной дискуссии.

Удалено модератором

Удалено модератором

> Германн ©   (27.08.08 01:33) [30]
> Вот именно такие аргументы я и "записываю". Тем более если
> эти аргументы высказаны в подобной дискуссии.


Тут Вам посоветовать ничего нельзя, не зная, что за приложение Вы разрабатываете.
А вдруг какй-нибудь OLAP-продвинутый построитель отчетов? Тогда может и надо его под разные базы затачивать. Или, тем более, - среду ETL. Так ей сам Бог велел!..

> Курдль   (27.08.08 12:39) [33]
>
>
> > Германн ©   (27.08.08 01:33) [30]
> > Вот именно такие аргументы я и "записываю". Тем более
> если
> > эти аргументы высказаны в подобной дискуссии.
>
>
> Тут Вам посоветовать ничего нельзя, не зная, что за приложение
> Вы разрабатываете.
> А вдруг какй-нибудь OLAP-продвинутый построитель отчетов?
>  Тогда может и надо его под разные базы затачивать. Или,
>  тем более, - среду ETL. Так ей сам Бог велел!..
>

Я в последнее время ничего сам не разрабатываю. Ну в отношении программ для РС. Но я записываю подобные аргументы для представления их тем, кто хочет создать ПО, которое записывает в БД данные (и показывает их), причем "независимо" от провайдера и типа БД.