Oracle для профессионалов
Открытость
Есть еще одна причина, почему при разработке часто выбирается сложный способ решения проблемы, — сложившееся представление, что надо жертвовать всем ради "открытости" и "независимости от СУБД". Разработчики хотят избежать использования "закрытых", "специфических" возможностей СУБД — иногда даже таких простых, как хранимые процедуры или последовательности, поскольку это привяжет их к определенной СУБД. Я настаиваю на том, что если создается приложение, читающее и изменяющее данные, оно уже в некоторой степени привязано к СУБД. Когда запросы начнут выполняться одновременно с изменениями, вы сразу обнаружите небольшие (а иногда — и большие) отличия в работе СУБД. Например, в одной СУБД может оказаться, что оператор SELECT COUNT(*) FROM T вступает во взаимную блокировку с простым изменением двух строк. В Oracle же запрос SELECT COUNT(*) никогда не блокирует другие сеансы. Мы уже рассматривали пример, когда в одной СУБД бизнес-правило работало как побочный эффект используемой модели блокирования, а в другой СУБД — нет. Было показано, что при одном и том же порядке выполнения транзакций в различных СУБД приложение может давать разные результаты. Причина — принципиальные различия в реализациях. Вы со временем поймете, что лишь очень немногие приложения можно непосредственно перенести из одной в другую СУБД. Различия в интерпретации (например, выражения NULL=NULL) и обработке операторов SQL будут всегда.
В одном из недавних проектов разработчики создавали Web-приложение с использованием Visual Basic, управляющих элементов ActiveX, Web-сервера IIS и СУБД Oracle 8i. Разработчики выразили опасение по поводу реализации бизнес-логики на языке PL/SQL - приложение становится зависимым от СУБД — и спрашивали, можно ли это исправить.
Меня этот вопрос несколько удивил. Просматривая список выбранных технологий, я не мог понять, чем им "не понравилась" зависимость от СУБД:
Все остальные технологии они выбрали так, что оказались привязанными к конкретной операционной системе — фактически свобода выбора оставалась только в отношении СУБД.
Независимо от того, что у них, видимо, были веские причины выбрать именно эти технологии, разработчики почему-то решили не использовать в полном объеме возможности критического компонента своей архитектуры и сделали это во имя "открытости". Мне кажется, что нужно сначала вдумчиво выбрать технологии, а затем максимально использовать предоставляемые ими возможности. За все эти технологии заплачены немалые деньги — не в ваших ли интересах максимально их использовать? Причем, создавалось впечатление, что они собирались воспользоваться преимуществами остальных технологий, так почему же для СУБД сделано исключение? На этот вопрос особенно сложно ответить, если учесть, что для эффективности приложения успешная работа с СУБД имеет первостепенное значение.
Можно рассмотреть это с точки зрения "открытости". Все данные помещаются в базу данных. СУБД, поддерживающая эту базу данных, — очень открытое средство. Она обеспечивает доступ к данным через SQL, с помощью компонентов EJB по протоколам HTTP, FTP, SMB и множества других протоколов и механизмов доступа. Пока все отлично: что может быть более открытым?
Затем вне базы данных добавляются алгоритмы и, что важнее, механизмы защиты. Например, в компоненты, обеспечивающие доступ к данным, или в код на Visual Basic, работающий на сервере Microsoft Transaction Server (MTS). В результате с открытостью базы данных покончено — она уже "закрыта". Пользователи теперь не могут использовать эти данные с помощью существующих технологий — они должны использовать предложенные методы доступа (или обращаться к данным в обход защиты). Сегодня это не кажется проблемой, но помните: то, что сегодня является "самой современной" технологией, например компоненты EJB, вчера было идеей, а завтра будет устаревшей, неэффективной технологией. Что осталось неизменным за последние 20 с лишним лет в мире реляционного программирования (да, собственно, и объектно-ориентированного) — это базы данных. Средства работы для пользователей меняются практически ежегодно, и по мере этого все приложения, самостоятельно, а не с помощью СУБД, реализующие защиту, становятся препятствиями на пути дальнейшего прогресса.
СУБД Oracle предлагает возможность детального контроля доступа (Fine Grained Access Control, FGAC, — ему посвящена глава 21). Если коротко, эта технология позволяет разработчику встраивать в базу данных процедуры, которые изменяют поступающие в базу данных запросы. Это изменение запросов используется для ограничения количества строк, которые клиент может получать или изменять. Процедура может определять, кто выполняет запрос, когда этот запрос выполняется, с какого терминала и т.д., и ограничивать соответствующим образом доступ к данным. С помощью FGAC можно организовать такую защиту, когда:
Эта возможность позволяет организовать контроль доступа в СУБД, непосредственно выдающей данные. Теперь уже неважно, получает ли пользователь данные через компоненты, страницы JSP, из приложения на VB с помощью ODBC или через SQL*Plus, — будут применяться одинаковые правила защиты. Вы готовы воспринять любую новую технологию.
Теперь я спрошу: какая технология более "открытая"? Та, что позволяет обращаться к данным только из кода VB и управляющих элементов ActiveX (замените язык VB языком Java, а компоненты ActiveX — компонентами EJB, если хотите; я говорю не о конкретной технологии, а о подходе)? Или та, что обеспечивает доступ из любой среды, способной взаимодействовать с СУБД, по столь отличающимся протоколам, как SSL, HTTP и Net8, или с помощью функциональных интерфейсов ODBC, JDBC, OCI и т. д.? Покажите мне средство создания отчетов, способное выполнять запросы к коду на VB. Я же назову десятки таких средств, выполняющих SQL-запросы.
Решение идти на жертвы ради независимости от СУБД и полной "открытости" волен принять каждый, и многие так и поступают, но я считаю такое решение ошибочным. Независимо от СУБД, ее функциональные возможности необходимо использовать в полной мере. Именно это, как правило, и делается на этапе настройки производительности (этим приходится заниматься сразу же после внедрения). Удивительно, как быстро отказываются от требования независимости, если использование специфических возможностей СУБД позволяет ускорить работу приложения в пять раз.
