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

Я видел, как разработчики в СУБД Oracle 8i создавали процессы-демоны, читающие сообщения из программных каналов (это механизм межпроцессного взаимодействия в СУБД). Процессы-демоны выполняли операторы SQL, содержавшиеся в прочитанных из программного канала сообщениях, и фиксировали сделанное. Это делалось для проверки транзакций, чтобы записи проверки откатывались при откате основной транзакции. Обычно если для проверки доступа к данным использовались триггеры и основной оператор впоследствии выполнить не удавалось, все изменения откатывались (см. главу 4, где неделимость операторов рассматривается более детально). Посылая же сообщение другому процессу, можно записывать информацию в другой транзакции и фиксировать ее независимо. Запись проверки при этом оставалась, даже если основная транзакция откатывалась. В версиях Oracle до Oracle 8i это был приемлемый (и практически единственный) способ реализации описанной функции. Когда я рассказал разработчикам об автономных транзакциях, поддерживаемых СУБД (мы их подробно рассмотрим в главе 15), они очень расстроились. Автономные транзакции, реализуемые добавлением единственной строки кода, делали то же, что вся их система. Положительным моментом оказалось то, что можно было выкинуть существенную часть кода и не поддерживать его в дальнейшем. Кроме того, система заработала быстрее и стала проще для понимания. Но их это все равно мало радовало, - очень уж много времени было потрачено на изобретение велосипеда. Особенно расстроился создатель процессов-демонов, плоды трудов которого были отправлены в мусорную корзину.

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

Решайте проблемы просто

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

Например, меня часто спрашивают: Как сделать, чтобы пользователь мог подключиться к базе данных только один раз? . (Есть еще сотня примеров, которые я мог бы здесь привести в качестве иллюстрации.) Наверное, это требование многих приложений; правда, в моей практике разработки такие приложения не встречались - я не вижу веской причины для того, чтобы ограничивать пользователей подобным образом. Однако другим разработчикам это нужно, и они обычно придумывают сложное решение. Например, создают пакетное задание, выполняемое операционной системой и просматривающее представление V$SESSION, а затем произвольно прекращающее сеансы пользователей, подключившихся к базе данных более одного раза. Или создают собственные таблицы, в которые приложение вставляет строку при регистрации пользователя и удаляет ее по завершении работы. Подобная реализация неизбежно приводит к многочисленным обращениям в службу поддержки, поскольку если приложение завершает работу нештатно, строка из этой таблицы не удаляется. Я видел еще много творческих способов добиться этого, но ни один из них не был таким простым:

ops$tkyte@0RA8I.W0RLD> create profile one session limit sessions per user 1; Profile created.

ops$tkyte@ORA8l.WORLD> alter user scott profile one session; User altered.

ops$tkyte@ORA8I.WORLD> alter system set resource limit=true; System altered.

Вот и все. Теперь любой пользователь с профилем ONE SESSION может подключиться только один раз. Простота этого решения обычно приводит разработчиков в восторг и вызывает запоздалые сожаления. Потратьте время на ознакомление с имеющимися средствами и их возможностями - это позволит сэкономить много времени и сил при разработке.

Тот же принцип делай проще применяется и на более высоком, архитектурном уровне. Я рекомендую подумать дважды, прежде чем браться за сложные реализации. Чем больше движущихся частей в системе, тем больше компонентов, которые могут работать неверно, а при использовании сложной архитектуры определить, что именно является причиной ошибки, будет непросто. Может быть, использование надцатиуров-невой архитектуры - это действительно круто , но лишено смысла, если в простой хранимой процедуре можно сделать то же самое, но лучше, быстрее и с использованием меньших ресурсов.

Я участвовал в разработке приложения, продолжающейся более года. Это было Web-приложение, используемое в масштабе компании. Клиент на базе HTML и с использованием технологии JSP динамически получал страницы с сервера промежуточного уровня, который взаимодействовал с CORBA-объектами, в свою очередь, обращавшимися к СУБД. CORBA-объекты должны б]ли поддерживать состояние и подключаться к СУБД для организации сеанса. В ходе тестирования этой системы оказалось, что потребуется много серверов приложений и очень мощная машина для работы СУБД, чтобы поддерживать 10000, как предполагалось, одновременно работающих пользователей. Более того, иногда возникала проблема нестабильности, связанная со сложностью взаимодействия

Открытость

Есть еще одна причина, почему при разработке часто выбирается сложный способ решения проблемы, - сложившееся представление, что надо жертвовать всем ради открытости и независимости от СУБД . Разработчики хотят избежать использования закрытых , специфических возможностей СУБД - иногда даже таких простых, как хранимые процедуры или последовательности, поскольку это привяжет их к определенной СУБД. Я настаиваю на том, что если создается приложение, читающее и изменяющее данные, оно уже в некоторой степени привязано к СУБД. Когда запросы начнут выполняться одновременно с изменениями, вы сразу обнаружите небольшие (а иногда - и большие) отличия в работе СУБД. Например, в одной СУБД может оказаться, что оператор SELECT COUNT(*) FROM T вступает во взаимную блокировку с простым изменением двух строк. В Oracle же запрос SELECT COUNT(*) никогда не блокирует другие сеансы. Мы уже рассматривали пример, когда в одной СУБД бизнес-правило работало как побочный эффект используемой модели блокирования, а в другой СУБД - нет. Было показано, что при одном и том же порядке выполнения транзакций в различных СУБД приложение может давать разные результаты. Причина - принципиальные различия в реализациях. Вы со временем поймете, что лишь очень немногие приложения можно непосредственно перенести из одной в другую СУБД. Различия в интерпретации (например, выражения NULL=NULL) и обработке операторов SQL будут всегда.

В одном из недавних проектов разработчики создавали Web-приложение с использованием Visual Basic, управляющих элементов ActiveX, Web-сервера IIS и СУБД Oracle 8i. Разработчики выразили опасение по поводу реализации бизнес-логики на языке PL/SQL - приложение становится зависимым от СУБД - и спрашивали, можно ли это исправить.

компонентов (ответить на вопрос, где именно и почему произошла ошибка в этой сложной системе, было трудно). Система масштабировалась, но требовала при этом огромных ресурсов. Кроме того, поскольку для реализации использовалось много сложных технологий, для разработки и сопровождения системы требовалось много опытных программистов. Мы разобрались в этой системе и ее предполагаемых функциях и поняли, что архитектура ее несколько сложнее, чем необходимо для решения поставленных задач. Мы увидели, что с помощью модуля PL/SQL сервера приложений Oracle iAS и ряда хранимых процедур можно было сделать такую же систему, работающую на существенно менее мощном оборудовании, причем усилиями менее опытных разработчиков. Никаких компонентов EJB, никаких сложных взаимодействий между страницами JSP и компонентами EJB - обычное преобразование указанного адреса URL в вызов хранимой процедуры. Эта новая система работает и используется до сих пор, поддерживает больше пользователей, чем предполагалось, и работает так быстро, что порой не верится. Она использует самую простую архитектуру, минимум компонентов, работает на дешевом 4-процессорном сервере уровня рабочих групп и никогда не дает сбоев (ну, один раз табличное пространство переполнилось, но это уже другая проблема).

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