как настраивать приложение с первого дня его создания;

как реализованы определенные компоненты СУБД и чем эта реализация отличается от обычно предполагаемой;

какие возможности реализованы в самой СУБД и почему, как правило, лучше ис-

пользовать предоставляемые СУБД функции, а не реализовать их самостоятельно;

зачем может понадобиться более глубокое знание языка SQL.

Этот список тем для начального изучения может показаться слишком длинным, но давайте рассмотрим следующую аналогию: если бы вы разрабатывали масштабируемое, высокопроизводительное приложение для абсолютно новой операционной системы (ОС), с чего бы вы начали? Надеюсь, ваш ответ: С изучения особенностей функционирования этой новой ОС, работы приложений в ней и т.п. . Если ответ принципиально другой, ваша разработка обречена на неудачу.

Рассмотрим, например, одну из ранних версий Windows (скажем, Windows 3.x). Она, как и ОС UNIX, была многозадачной операционной системой. Однако эта многозадачность была не такой, как в ОС UNIX, - использовалась модель невытесняющей многозадачности (т.е., если работающее приложение не возвращает управление, ничто другое работать не может, включая операционную систему). Фактически, по сравнению с UNIX, Windows 3.x вообще не была многозадачной ОС. Для создания эффективных приложений разработчики должны были точно знать, как реализована возможность многозадачности Windows. Если необходимо разрабатывать приложение, работающее непосредственно в среде определенной ОС, понимание особенностей этой ОС очень важно.

То, что верно в отношении приложений, непосредственно работающих в среде операционной системы, верно и для приложений, работающих в среде СУБД: понимание особенностей СУБД является определяющим фактором успеха. Если вы не понимаете, что делает используемая СУБД или как она это делает, создаваемое приложение не будет работать успешно. Предположение о том, что успешно работающее в среде SQL Server приложение так же успешно будет работать и в среде Oracle, скорей всего не оправдается.

Мой подход

Прежде чем начать, хотелось бы объяснить вам мой подход к разработке. Я предпочитаю решать большинство проблем на уровне СУБД. Если что-то можно сделать в СУБД, я так и сделаю. Для этого есть две причины. Первая и главная состоит в том, что если встроить функциональность в СУБД, то ее можно будет применять где угодно. Я не знаю серверной операционной системы, для которой нет реализации СУБД Oracle. Одна и та же СУБД Oracle со всеми опциями работает везде - от Windows до десятков версий ОС UNIX и больших ЭВМ типа OS/390. Я часто разрабатываю и тестирую программы на моем портативном компьютере, где работает СУБД Огас1е8/для Windows NT. А применяются эти программы на различных серверах с ОС UNIX, на котор1х работает та же версия СУБД. Если приходится реализовать функциональность за пределами

Разработка успешных приложений для Oracle 39

СУБД, ее очень сложно переносить на любую другую платформу. Одна из основных особенностей, делающих язык Java привлекательным для многих разработчиков, состоит в том, что программы всегда компилируются в одной и той же виртуальной среде, виртуальной машине Java Virtual Machine (JVM), и поэтому максимально переносимы. Именно эта особенность привлекает меня в СУБД. СУБД Oracle - это моя виртуальная машина, моя виртуальная операционная система .

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

Таким образом, зная лишь особенности работы одной виртуальной ОС , можно создавать приложения, демонстрирующие отличную производительность и масштабируемость во многих операционных системах. Я не утверждаю, что можно полностью игнорировать базовую ОС, - просто разработчик приложений баз данных достаточно хорошо от нее изолирован, и ему не придется учитывать многие ее нюансы. Ваш АБД, отвечающий за поддержку СУБД Oracle, должен знать намного больше об особенностях базовой ОС (если не знает - найдите нового АБД!). При разработке клиент-серверного программного обеспечения, если основная часть кода вынесена из СУБД и виртуальной машины (наиболее популярной виртуальной машиной, вероятно, является Java Virtual Machine), разработчику придется учитывать особенности ОС сервера.

При разработке приложений баз данных я использую очень простую мантру:

если можно, сделай это с помощью одного оператора SQL;

если это нельзя сделать с помощью одного оператора SQL, сделай это в PL/SQL;

если это нельзя сделать в PL/SQL, попытайся использовать хранимую процедуру на языке Java;

если это нельзя сделать в Java, сделай это в виде внешней процедуры на языке С;

если это нельзя реализовать в виде внешней процедуры на языке С, надо серьез-

но подумать, зачем это вообще делать...

В книге вы увидите применение этого подхода. Мы будем использовать язык PL/SQL и его объектные типы для реализации того, что нельзя сделать в SQL. Язык PL/SQL существует давно, за ним стоит более тринадцати лет настройки, и нет другого языка, настолько тесно интегрированного с языком SQL и настолько оптимизированного для взаимодействия с SQL. Когда возможностей PL/SQL оказывается недостаточно, например, при доступе к сети, отправке сообщений электронной почты и т.п., мы будем использовать язык Java. Иногда мы будем решать определенные задачи с помощью языка С, но обычно лишь в тех случаях, когда программирование на С - единственно возможный вариант или когда обеспечиваемая компилятором С скорость работы программы действительно необходима. Во многих случаях сейчас последняя причина отпадает при использовании компиляции в машинные коды программ на языке Java (возможности преобразовать байт-код Java в специфический объектный код операционной системы

для данной платформы). Это обеспечивает программам на Java такую же скорость работы, как и у программ на языке С.

Подход с использованием принципа черного ящика

У меня есть предположение, основанное на личном опыте, почему так часто разработка приложений баз данных заканчивается неудачно. Позвольте уточнить, что к разряду неудавшихся разработок я отношу также проекты, официально не признанные неудавшимися, но потребовавшие на разработку и внедрение намного больше времени, чем планировалось первоначально, поскольку пришлось их существенно переписывать , перепроектировать или настраивать . Лично я такие не завершенные в строк проекты считаю неудавшимися: очень часто их вполне можно было завершить вовремя (и даже досрочно).

Наиболее типичной причиной неудачи является нехватка практических знаний по используемой СУБД - элементарное непонимание основ работы используемого инструментального средства. Подход по принципу черного ящика требует осознанного решения: оградить разработчиков от СУБД. Их заставляют не вникать ни в какие особенности ее функционирования. Причины использования этого подхода связаны с опасениями, незнанием и неуверенностью. Разработчики слышали, что СУБД - это сложно , язык SQL, транзакции и целостность данных - не менее сложно . Решение: не заставлять никого делать что-либо сложное . Будем относиться к СУБД, как к черному ящику, и найдем инструментальное средство, которое сгенерирует необходимый код. Изолируем себя несколькими промежуточными уровнями, чтобы не пришлось сталкиваться непосредственно с этой сложной СУБД.

Такой подход к разработке приложений баз данных я не мог понять никогда. Одна из причин, почему мне трудно это понять, состоит в том, что для меня изучение языков Java и С оказалось намного сложнее, чем изучение основ работы СУБД. Я сейчас очень хорошо знаю языки Java и С, но для их освоения мне понадобилось намного больше практического опыта, чем для достижения соответствующего уровня компетентности при использовании СУБД. В случае СУБД необходимо знать, как она работает, но детали знать необязательно. При программировании на языке С или Java, необходимо, например, знать все особенности используем1х компонентов; кроме тою, это очень большие по объему языки.

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

Вот типичный сценарий такого рода разработки.

Разработчики были полностью обучены графической среде разработки или соответствующему языку программирования (например, Java), использованных для создания клиентской части приложения. Во многих случаях они обучались несколько недель, если не месяцев.