• Типы инструментальных средств
• Какие критерии отбора важны?
• Инструментальные средства для систем клиент/сервер
• Проектирование для World Wide Web

У одного из авторов еще живо в памяти воспоминание о том, как он пытался уговорить клиента-консультанта написать всего один модуль (из почти 750) на Рго*С, а не на PL/SQL. Руководитель проекта настаивал на том, что поскольку PL/SQL является корпоративным стандартом, то следует использовать этот язык. В соответствующем разделе отчета консультанта было написано:

Новый руководитель проекта больше года старался решить проблемы производительности средствами PL/SQL, пробуя вариант за вариантом, после чего наконец санкционировал написание этого модуля на Рго*С. Для создания и тестирования понадобилась неделя работы одного программиста, и проблемы производительности были решены.

На практике в настоящий момент времени широко распространены только первые два способа. Третий начинает выглядеть как вариант для Web-приложений и для развертывания архитектуры сетевых вычислений Oracle (NCA). Без сомнения, в Oracle есть люди, считающие, что это одно и то же и что каждый Oracle-узел, развертывающий Web-приложения, автоматически принимает NCA.

Некоторые продукты, например Powerbuilder фирмы Powersoft, позволяют выбрать любой из двух вариантов SQL-соединений, поэтому важно знать о различиях между ними. Во-первых, для использования ODBC необходим ODBC-драйвер, хотя необходимые драйверы довольно часто продаются в комплекте с инструментальными средствами. При использовании SQL*Net можно свободно писать SQL-код, включающий Oracle-расширения стандарта ANSI. Если же применяется ODBC-драйвер, он может попытаться разобрать этот SQL-код и отклонить SQL, не соответствующий стандарту ANSI.

Это ограничение приводит к появлению проблем, когда мы пытаемся проектировать экранную форму, позволяющую администратору приложения сопровождать пользователей, поскольку такие команды, как ALTER USER и DROP USER в стандарте ANSI отсутствуют. Это ограничение касается почти всех DCL- и DDL-операций в Oracle7. Документ The Oracle7 Server SQL Reference Manual содержит перечень Oracle-расширений стандартного SQL, а руководство для версии 7.2 — список более чем 60 команд SQL, поддерживаемых Oracle7, но не входящих в стандартный SQL. Для тех, кто не знаком с ограниченной областью применения стандарта (стандартов) на SQL, сообщаем, что этот список включает команду CREATE SYNONYM.

В большинстве ODBC-драйверов это ограничение ANSI можно обойти, установив опцию, называемую режимом ретрансляции (pass through mode). Этот режим заставляет драйвер передавать SQL прямо на сервер, не интерпретируя его. Это позволяет использовать SQL, не соответствующий стандарту ANSI, но лишает нас одного из главных преимуществ ODBC, которое заключается в следующем. Если режим ретрансляции не применяется, то приложение можно сделать независимым от базы данных. Это значит, что теоретически оно должно работать с Oracle7, Sybase, SQL Server, Informix и т.д. Если это важно — например, в случае, когда создается продукт, который планируется продавать на более широком рынке, чем рынок серверов Oracle7, — то следует в качестве стандарта разработки применять ODBC без режима ретрансляции. Однако в этом случае вам пригодится лишь очень малая часть нашей книги (не считая раздела о псевдокоде).

Иногда режим ретрансляции включают из-за того, что предполагают, будто наличие промежуточного ПО (ODBC-драйвера, интерпретирующего SQL) влечет очень высокие затраты и сильно замедляет работу приложения. Однако это зависит от конкретного ODBC-драйвера. Ведь ODBC — это просто стандарт, и на рынке есть множество драйверов. Некоторые из них обеспечивают высокую скорость работы вне зависимости от режима. Опять-таки, ценным подспорьем здесь могут быть оценка по результатам макетирования и эталонные тесты драйверов. Следует помнить одно: если ODBC-драйвер интерпретирует и переписывает SQL, он может удалить встроенные комментарии, в том числе и те, которые являются подсказками оптимизатору Oracle7. Это серьезно ограничит возможность воздействия на сервер при оптимизации производительности некоторых SQL-запросов.

В заключение скажем, что в первом стандарте на ODBC (ODBC 1) программа может вызывать хранимую процедуру или функцию базы данных и передавать ей параметры. Однако такая процедура не может возвращать значения в вызывающую программу. Это существенно ограничивало возможности проектирования интерфейса клиент/сервер, так как хранимые процедуры обычно играют здесь важную роль. В стандарте ODBC 2.0 это упущение исправлено.

Если рассматривается возможность использования Microsoft Visual Basic или Visual C++ в качестве внешней системы, существует альтернатива ODBC (или встроенному SQL) — Oracle Objects for OLE (OO4O). По стилю программирования этот продукт очень похож на ODBC, но написан специально для сервера Oracle7 и, следовательно, оптимизирован под Oracle.

Некоторые средства разработки для клиентов имеют встроенную СУБД. Это может быть полезно для разработки на базе ПК, поскольку в противном случае нам потребуется доступ к серверу Oracle7 (или к Personal Oracle7, если на ПК достаточно оперативной памяти). Вот некоторые примеры:

Эти СУБД не обладают всеми функциональными возможностями Oracle7. В частности, они не поддерживают ограничения целостности и компоненты кода, такие как триггеры и хранимые процедуры. Эти ограничения диктуют уровень, до которого может успешно продолжаться разработка в автономной конфигурации, что делает Personal Oracle7 гораздо более приемлемым вариантом. Недавно Oracle представила продукт Oracle Lite, который способен работать в одном мегабайте оперативной памяти, но это, опять-таки, весьма ограниченная СУБД, нацеленная, скорее, на рынок встроенных систем, нежели на рынок приложений.

Мы можем описать предыдущую категорию как клиентское инструментальное средство разработки со встроенной СУБД, которое может также обращаться к удаленной БД на сервере, обычно посредством ODBC. Есть еще один тип комбинации инструментального средства разработки с базой данных — эту категорию продуктов можно назвать клиентской СУБД со встроенными средствами разработки. Примеры средств этой категории — Microsoft Access и Borland Paradox.

При проектировании систем клиент/сервер с помощью таких средств следует помнить об одной ловушке. Мы можем (сознательно) решить использовать локальную базу данных для хранения определенных неизменчивых данных, например справочных. Присоединяя локальные таблицы к серверным таблицам, мы, по сути дела, оказываемся в "сумеречной зоне" распределенной базы данных. Мы хотим, чтобы серверная БД оставалась под нашим контролем, поскольку именно там расположена основная масса наших данных и средств обработки. Однако иногда клиентская база данных начинает борьбу за власть и пытается взять все в свои руки. Из серверной базы данных в клиентскую загружаются большие таблицы (часто целиком) для последующего соединения с локальной таблицей на клиенте (см. рис. 19.1). Очевидно, что такие стратегии катастрофически ухудшают производительность.

Рис. 19.1. Проблемы, возникающие при попытках диспетчера клиентской базы данных взять все под свой контроль

Некоторые клиентские средства разработки систем генерируют код, который не может использовать ни общедоступные, ни частные синонимы, определенные в базе данных. Некоторые средства могут работать только для пользователя, владеющего данной таблицей, поскольку они не поддерживают табличные ссылки, в которых в качестве префикса используется имя схемы (schema.table). Если в оцениваемом средстве разработки это имеет место, необходимо рассмотреть возможные последствия для безопасности — например, в случае, если всем нужно подключаться к базе данных под одним и тем же пользовательским идентификатором.

Многие новые приложения будут разрабатываться в расчете на развертывание через Web-броузеры. В организациях, где у будущих пользователей уже есть какой-нибудь Web-броузер, трудно увидеть причину, по которой новое приложение вдруг может захотеть пользоваться другим интерфейсным инструментом. Говоря так, мы не предлагаем открывать все новые приложения всему всемирному Web-сообществу. Мы просто отмечаем, что броузерная технология создает очень удобный способ развертывания нового приложения по интранет, а не по Интернет. Для того чтобы разделить эти сети, нужно либо вообще не подключать внутреннюю сеть к Интернет, либо поставить надежный брандмауэр.

Однако следует отметить, что если вы предполагаете двинуться поэтому пути, то мы настоятельно рекомендуем обратиться к трехуровневым архитектурам и удалить из кода пользовательского интерфейса все прямые ссылки на базу данных. Эти ссылки следует поместить на сервер (серверы) приложений. На рис. 19.2 мы показали только один сервер приложений и две базы данных, которые некоторые приложения могут сопровождать отдельно, а некоторые — вместе.