Функциональные возможности

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

Как упоминали раньше, отвечать на вопросы о СУБД Oracle, задаваемые в Вебе. 80 процентов моих ответов – просто ссылки на документацию. Пользователи спрашивают, как написать какие-то сложные фрагменты кода, используя функциональные средства СУБД (или за пределами ее). Только показываю им фрагмент документации, описывающий уже готовую реализацию этой логики в СУБД Oracle и правила ее использования. Это позволяет быстро получать ответы. Мне задают вопрос: "Я хочу где-нибудь сохранять копию своих данных. Нужно обновлять ее только один раз в сутки, в полночь. Как мне написать для этого код?" Ответ простой: оператор CREATE SNAPSHOT (создать моментальную копию данных). Это и есть функциональное средство, встроенное в СУБД.

Верно, вы можете написать собственную процедуру тиражирования данных, вы даже можете сделать это ради забавы, но в конце рабочего дня заниматься этим не очень разумно. Вообще говоря, СУБД может сделать это лучше вас. Тиражирование, например, реализовано в ядре СУБД, написанном на языке C. Оно быстро работает, достаточно просто в использовании и надежно. Оно работает в разных версиях на разных платформах. Оно поддерживается, поэтому если вы столкнетесь с проблемами, группа поддержки корпорации Oracle рада будет помочь вам. Если вы перейдете на новую версию СУБД, тиражирование будет поддерживаться по-прежнему, возможно, с какими-то новыми функциональными возможностями. Теперь рассмотрим вариант, который вы могли бы разработать сами. Вы должны обеспечить его поддержку во всех версиях СУБД, которые вам нужно поддерживать. Совместимость СУБД версий 7.3, и 8.0, и 8.1, и 9.0 и т.д. – вот что будет вашей заботой. Если произойдет сбой, вы не сможете обратиться к группе поддержки. Если выйдет новая версия СУБД Oracle, вы должны будете перенести свою процедуру тиражирования в эту версию.

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

Это и сделали разработчики. Они создали ряд процессов и разработали API (Application Programming Interface – интерфейс прикладного программирования) для организации очередей сообщений. Они затратили на это значительное количество человеко-часов и были уверены, что создали уникальное средство. Сразу же, как только мне показали его и рассказали о функциональных возможностях, мне оставалось только сказать: "Advanced Queues" – средства организации очередей в СУБД Oracle. Это собственные средства СУБД. Они решают проблему "получения первой незаблокированной строки в таблице очередей и блокирования ее". Но разработчики, не зная о существовании такой возможности, затратили массу времени и энергии на разработку собственных средств. Кроме затрат в прошлом, они будут тратить массу времени на сопровождение в будущем. Их руководитель был больше чем поражен, узнав, что уникальный фрагмент программного обеспечения на самом деле имитирует собственные средства СУБД.

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

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