Oracle для профессионалов Том Кайт торгово-издательский дом DiaSoft

 SELECT COUNT(*) FROM
T вступает во взаимную блокировку с простым
изменением двух строк. В Oracle же запрос
 SELECT COUNT(*)
никогда не блокирует
другие сеансы. Мы уже рассматривали пример, когда в одной СУБД бизнес-правило
работало как побочный эффект используемой модели блокирования, а в другой СУБД —
нет. Было показано, что при одном и том же порядке выполнения транзакций в различ-
ных СУБД приложение может давать разные результаты. Причина — принципиальные
различия в реализациях. Вы со временем поймете, что лишь очень немногие приложе-
ния можно непосредственно перенести из одной в другую СУБД. Различия в интерпре-
тации (например, выражения
 NULL=NULL)
и обработке операторов
 SQL
будут всегда.
В одном из недавних проектов разработчики создавали Web-приложение с исполь-
зованием Visual Basic, управляющих элементов ActiveX, Web-сервера
 IIS
и СУБД
Oracle 8i. Разработчики выразили опасение по поводу реализации бизнес-логики на язы-
ке PL/SQL — приложение становится зависимым от СУБД — и спрашивали, можно ли
это исправить.

---

Разработка успешных приложений для Oracle
Меня этот вопрос несколько удивил. Просматривая список выбранных технологий,
я не мог понять, чем им "не понравилась" зависимость от СУБД:
О они выбрали язык программирования, привязанный к определенной операци-
онной системе и поддерживаемый единственным производителем (можно было
выбрать язык Java);
• они выбрали технологию создания компонентов, привязывающую к одной опе-
рационной системе и производителю (они могли выбрать технологию EJB или
CORBA);
• они выбрали Web-сервер, работающий на единственной платформе того же про-
изводителя (почему не Apache?).
Все остальные технологии они выбрали так, что оказались привязанными к к о н к -
ретной операционной системе — фактически свобода выбора оставалась только в отно-
шении СУБД.
Независимо от того, что у них, видимо, были веские причины выбрать именно эти
технологии, разработчики почему-то решили не использовать в полном объеме возмож-
ности критического компонента своей архитектуры и сделали это во имя "открытости".
Мне кажется, что нужно сначала вдумчиво выбрать технологии, а затем максимально
использовать предоставляемые ими возможности. За все эти технологии заплачены не-
малые деньги — не в ваших ли интересах максимально их использовать? Причем, со-
здавалось впечатление, что они собирались воспользоваться преимуществами остальных
технологий, так почему же для СУБД сделано исключение? На этот вопрос особенно
сложно ответить, если учесть, что для эффективности приложения успешная работа с
СУБД имеет первостепенное значение.
Можно рассмотреть это с точки зрения "открытости". Все данные помешаются в базу
данных. СУБД, поддерживающая эту базу данных, — очень открытое средство. Она обес-
печивает доступ к данным через SQL, с помощью компонетов EJB, по протоколам