ЛП...мс акссес ебай эдишн
:)
толково.
:)

ПсихиатрПравда интересно разговаривать сам с собой? Клинический случай - заявляю авторитетно
Ну да. Вот так и живу. Ведь разговаривать мне больше и не с кем.
http://www.youtube.com/watch?v=ENApxvijIio&feature=related

Павел-ПКак я понимаю в высоконагруженных проектах встречаются и проблемы с БД.
Например: deadlock-и, блокировки одних запросов другими и т.д.

1. Такие вещи гораздо легче решаются когда доступ к БД осуществляется через слой хранимых процедур. Другое дело, что на разработку/поддержку этого слоя приходится тратить уйму времени.
2. Решать же подобные проблемы при доступе к БД напрямую из приложения не очень легко. Каждый пишет что хочет и где хочет. Определить какие действия приложения вызвали deadlock, блокировку требует больших усилий.

И вновь прошу прощения.
как акцессник вам говорю - вы демонизируете роль "хранимых процедур".

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

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

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

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

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

PS
Сегодня обнаружил, что практически та же по содержанию тема одномоментно обсуждается в
форуме "Разработка информационных систем".
Занятно.

Yo.!
...
интересно, что за язык вне субд сможет выдать аналог %rowtype или отследить какие куски кода перестали работать после того как дба накатил DDL-патчик который подправил структуру бд ?

ЗЫ. искренне порадовался за бесценных pl/sql программеров, которых уже почти нет и потому у них почти не стоит. я ваш пассаж верно понял ?
1) я недостаточно образован в pl\sql, для того, чтобы сообразить, в каких обстоятельствах может иметь значение %rowtype.
Отвечу вам так:
добавление поля администратором никакой фактически написанный код не заметит - ни использующий %rowtype, ни обошедшийся без него. Если только не делается технических ошибок вида
(что не во всех обстоятельствах даже может быть за ошибку принято)

А вот удаление (или переименование) поля заметит любой код ( как использующий %rowtype, так и нет), фактически обращяющийся к этому коду. Нет разницы


или

для развала pl/sql-кода в случае удаления поля.
Т.е., с точки зрения необразованного акцессника - %rowtype - сам по себе - почти целиком мимо кассы в качестве страховочного механизма.

Что касается компиляции хранимого в субд серверного кода как инструмента, удостоверяющего, что "система поднимется" - да, такую роль компиляция серверного кода играет.
(Я так понимаю, что случай динамического исполнения pl/sql-кода мы не рассматриваем)

Но система и при альтернативном подходе как-нибудь да стартует....
Да, какие-то механизмы, вроде статической компиляции такой, при которой автоматически проверяется валидность имен объектов бд выглядит как желательные. Так или иначе - это технологический элемент и каким-то образом, вплоть до административных мер, он может быть затребован к обеспечению. (создатели орм-ов, кстати, клянутся, что нечто подобное, при определенном способе обращения с их поделиями, может быть достигнуто. На практическом уровне я в этом ничего не понимаю.)

(правильная работа системы в любом случае не обещана. )

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

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

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

Особенности физиологии программистов pl/sql - вам, вероятно, должны быть виднее.