Oracle для профессионалов



              

Возможности и функции - часть 2


Недостаточное понимание того, что предлагает СУБД, может серьезно помешать в будущем. Недавно разработчики демонстрировали мне созданное ими "очень нужное" программное обеспечение. Это была система обмена сообщениями, решавшая проблему очередей в базе данных. Она обычно возникает при необходимости использования таблицы несколькими сеансами в качестве "очереди". Необходимо, чтобы несколько пользователей могли заблокировать очередную запись, пропустив все уже заблокированные записи (они уже обрабатываются). Проблема в том, что нет задокументированной возможности СУБД для пропуска заблокированных строк. Поэтому, не зная о существовании средств, предоставляемых СУБД Oracle, можно приняться за реализацию поддержки очередей самостоятельно (или приобрести готовое решение).

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

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

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




Содержание  Назад  Вперед