Oracle для профессионалов
Возможности и функции
Противники обязательного обеспечения "независимости от СУБД" приводят следующий аргумент: нужно хорошо понимать, что именно предлагает конкретная СУБД, и полностью использовать ее возможности. В этом разделе не описываются все уникальные возможности Oracle 8i, — для этого понадобилась бы отдельная большая книга. Новым возможностям СУБД Oracle 8i посвящена специальная книга в наборе документации по СУБД Oracle. Если учесть, что вместе с СУБД Oracle поставляется документация общим объемом около 10000 страниц, детальное рассмотрение каждой возможности и функции практически нереально. В этом разделе просто показано, почему даже поверхностное представление об имеющихся возможностях дает огромные преимущества.
Как уже было сказано, я отвечаю на вопросы о СУБД Oracle на Web-сайте. Если честно, процентов 80 моих ответов — ссылки (URL) на документацию. Меня спрашивают, как реализовать те или иные сложные функциональные возможности в базе данных (или вне ее). А я просто даю ссылку на соответствующее место в документации, где написано, как это уже реализовано в СУБД Oracle и как этими возможностями пользоваться. Часто такие случаи бывают с репликацией. Я получаю вопрос: "Хотелось бы сохранять копию данных в другом месте. Эта копия должна быть доступна только для чтения. Обновление должно выполняться раз в сутки, в полночь. Как написать соответствующий код?". Ответ простой: см. описание команды CREATE SNAPSHOT. Вот что такое встроенные возможности СУБД.
Можно, конечно, для интереса написать собственный механизм репликации, но это будет не самое разумное действие. СУБД делает многое и, как правило, лучше, чем создаваемые нами приложения. Репликация, например, встроена в ядро, написанное на языке C. Она работает быстро, сравнительно проста в использовании и надежна. Работает в разных версиях, на разных платформах. При возникновении проблем служба поддержки Oracle поможет их решить. После обновления версии репликация будет поддерживаться с новыми, дополнительными возможностями. Теперь предположим, что вы разработали собственный механизм репликации. Вам придется заняться его поддержкой во всех версиях СУБД, которые вы собираетесь поддерживать. Одинаковое функционирование в версии 7.3, 8.0, 8.1 и 9.0 и так далее вы должны будете обеспечивать сами. Если произойдет сбой, обращаться будет не к кому. По крайней мере, пока не удастся получить маленький тестовый пример, демонстрирующий основную проблему. При выходе новой версии вам придется самостоятельно переносить в нее код механизма репликации.
Недостаточное понимание того, что предлагает СУБД, может серьезно помешать в будущем. Недавно разработчики демонстрировали мне созданное ими "очень нужное" программное обеспечение. Это была система обмена сообщениями, решавшая проблему очередей в базе данных. Она обычно возникает при необходимости использования таблицы несколькими сеансами в качестве "очереди". Необходимо, чтобы несколько пользователей могли заблокировать очередную запись, пропустив все уже заблокированные записи (они уже обрабатываются). Проблема в том, что нет задокументированной возможности СУБД для пропуска заблокированных строк. Поэтому, не зная о существовании средств, предоставляемых СУБД Oracle, можно приняться за реализацию поддержки очередей самостоятельно (или приобрести готовое решение).
Именно это и сделала упомянутая группа разработчиков. Они создали набор процессов и придумали функциональный интерфейс для организации очередей сообщений в СУБД. Они потратили на это немало времени и сил и были уверены, что сделали нечто действительно уникальное. Когда я увидел систему в действии и узнал ее функциональные возможности, мне осталось сказать лишь одно: это аналог расширенной поддержки очередей, Advanced Queues. Эта возможность давно встроена в СУБД. Она решает задачу "получить первую незаблокированную запись в очереди и заблокировать ее". Все, что нужно, уже сделано. Разработчики, не зная о существовании такой возможности, потратили на ее реализацию много времени и сил. Кроме того, им придется тратить немало времени и на ее поддержку в дальнейшем. Их руководитель не очень обрадовался, узнав, что вместо уникального программного обеспечения получилась эмуляция встроенной возможности СУБД.
Я видел, как разработчики в СУБД Oracle 8i создавали процессы-демоны, читающие сообщения из программных каналов (это механизм межпроцессного взаимодействия в СУБД). Процессы-демоны выполняли операторы SQL, содержавшиеся в прочитанных из программного канала сообщениях, и фиксировали сделанное. Это делалось для проверки транзакций, чтобы записи проверки откатывались при откате основной транзакции. Обычно если для проверки доступа к данным использовались триггеры и основной оператор впоследствии выполнить не удавалось, все изменения откатывались (см. главу 4, где неделимость операторов рассматривается более детально). Посылая же сообщение другому процессу, можно записывать информацию в другой транзакции и фиксировать ее независимо. Запись проверки при этом оставалась, даже если основная транзакция откатывалась. В версиях Oracle до Oracle 8i это был приемлемый (и практически единственный) способ реализации описанной функции. Когда я рассказал разработчикам об автономных транзакциях, поддерживаемых СУБД (мы их подробно рассмотрим в главе 15), они очень расстроились. Автономные транзакции, реализуемые добавлением единственной строки кода, делали то же, что вся их система. Положительным моментом оказалось то, что можно было выкинуть существенную часть кода и не поддерживать его в дальнейшем. Кроме того, система заработала быстрее и стала проще для понимания. Но их это все равно мало радовало, — очень уж много времени было потрачено на изобретение велосипеда. Особенно расстроился создатель процессов-демонов, плоды трудов которого были отправлены в мусорную корзину.
С подобными случаями я сталкиваюсь постоянно: затрачиваются громадные усилия на решение проблем, уже давно решенных в самой СУБД. Если вы не потратите время на изучение того, что предлагается, рано или поздно будете наказаны, изобретая велосипед. Во второй части книги, "Структуры и утилиты базы данных", мы детально рассмотрим отдельные функциональные возможности, предлагаемые СУБД. Я выбрал те возможности и функции, которые часто используют разработчики или которые стоило бы использовать намного чаще. Описана будет, однако, лишь вершина айсберга. В СУБД Oracle намного больше средств и возможностей, чем можно описать в одной книге.
