2ASCRUS
Попробую показать на примере :)

Мне надо сделать интерфейс обработки объекта..
При этом заранее неизвестно ни
число параметров, ни их тип
/например, я готовлю отчет по прсроченной
дебиторской задолженности, мне нужен
универсальный обработчик, ктр постоянно будет
изменяться и выдавать поток данных по различным
срокам, видам оплат и т.п./

Для открытой разработки важно, чтобы этот интерфейс
мог модифицироваться без изменения всех остальных
модулей, ктр с ним взаимодействуют ...

Стандартное решение - пишется заглушка, ктр
выдает сначала всю дебиторку...
Через неделю нужно выделить только дебиторку
менеджера Иванова.
Есть 3 задачи
1. где-то в клиенте выбрать параметр - менеджер
и занести значение Иванов
2. передать это значение обработчику /в простейшем
случае ХП/
3. дописать обработчик

При решении "в лоб" - надо модифицировать и
перетранслировать все модули, вкл клиента...

"Открытый" подход состоит в том, что где-то в стороне
есть отдельный кусок, в ктр организован выбор
параметра /модификация этого куска не затрагивает
остальные части клиента!/.
Куда-то значение этого параметра надо засовывать, чтобы ротом анализировать в обработчике.
Стандартное решение - создать таблицу, где хранятся эти параметры и их значения.
Просто таблица код параметра - значение приведет
к конфликтам /один выбрал Пупкина, другой в то же время- Васькина/. Причем, даже анализ логина / по аналогу временных таблиц в Oracle/ не решает проблему - может быть запущено несколько клиентов /в т.ч. различных приложений/, ктр будут мешать друг другу.
Использование временных таблиц позволяет организовать независимое и развиваемое (!!!) взаимодействие различных модулей и передачу параметров между ними.

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

Это - наиболее очевидное преимущество /хотя, пожалуй,
не единтсвенное и даже, наверное, не самое главное :)/

2Zaxx
Возможно...
Поскольку я уже года 2 не имел дела
с Oracle, может, я просто этого и не знаю.
По приведенному тексту похоже, что так оно и есть ...

2Ora600
Не передергивайте...
Я утверждал, что MS SQL удобнее с моей точки зрения
Это естественно, поскольку я имел с ним дела в 2-3
раза дольше, чем с Oracle /не говоря уже о том,
что Oracle намного больше и сложнее MS/..

Что касается вопорса насчет программист ли я?
Он звучит более чем странно...
Суди сам
- Любой проект начинается с постановки,
естественно, основное внимание уделяется
предметной области, ее законам и функционированию
Следующее по приоритету - технология разработки,
возможность создавать модульные проекты, легко
изменяемые и переносимые.
Технические вопросы, в т.ч. "кишки СУБД" при таком
/думаю, оправданном :)/ подходе имеют
третьестепенное значение.
В этом случае, вполне возможно, что некоторых
особенностей я и не знаю /до сих пор много интересного
и нового нахожу на форумах MS и Delphi/...
Не правда ли, такой подход практичнее, чем
разбираться в инструментарии "до самых винтиков"
/тем более, что на моей памяти с 1986 г эти
инчструментарии меняются с бешенной скоростью :)/

Не горячись, Ora600....
Успокойся..
Как раз в отм и дело, что я все это время
решал конкретный задачи и строил эффективные
системы, а не возился с инструментарием...

Думаю, форум и есть место для обсуждения разных точек зрения... Есть сермяга и в том, что первична,
все же постановка задачи /она решает сильно много/, бывали и ошибки, связанные с недостаточным знанием инструментария /кстати, благодарен Zaxx-y за временные таблицы в Oracle, думаю, будет возможность еще проверить/.
А ситуация чаще наоборот - есть люди, решающие реальные проблемы /например, тот же биллинг/, а есть техники, ктр ковырются в железяках. Первые без вторых, может не всегда найдут самый оптимальный путь, зато вторые без первых вообще никому не нужны :)...

Вдогонку to Ora600
Кстати, сам очень недолюбливаю SAP ...

Нет, Эдвард,
за сильную жесткость и громоздкость :)
Была пара задач /до проектов не дошли ../
То, что там предлагалось сделать на R3,
мы уже эффективнее делали раньше /правдо,
по большей части в рамка интеграции .../