Технология Клиент-Сервер 1999'3
	Home Поиск Издания Контакты k-press.ru

Продолжается подписка на наши издания! Вы не забыли подписаться?

Oracle8i (Oracle 8.1.5)

Когда речь заходит о SQL-серверах, корпоративных базах данных и прочих подобных предметах, слову "Oracle" всегда найдется место. Говорят, что никого не увольняли за покупку продукции IBM. То же самое говорят и про софт от Microsoft. Так вот, никто не скажет, что разработчик ошибся, если он в качестве платформы для управления данными выбрал решения от Oracle.

Oracle - фирма №2 в программном бизнесе (ну, по крайней мере, по оборотам). Однако, в отличие от Microsoft, Oracle - компания одного продукта. Разумеется, "один" - это условность, Oracle выпускает массу приложений (например, Oracle Applications) и утилит, но в сознании большинства Oracle - это сервер БД и сопутствующие ему средства (где бы были Oracle Applications, не будь на свете RDBMS Oracle). Но в сознании большинства Oracle - это очень сложно. Если человек носит гордое звание "Oracle DBA", он наверняка семи или более пядей во лбу, единственной радостью жизни считает писание заковыристых скриптов на PL/SQL с помощью великого текстового редактора SQL*Plus и может составить в уме такой SQL-запрос, на который и сотня SQL-серверов ответить не смогут.

Так ли это? Попробуем разобраться.

Установка

Семейство продуктов БД

Наиболее свежей версией сервера Oracle является версия 8i. Буква i в данном случае очевидно означает Internet, и Oracle позиционирует эту версию как шаг вперед от технологии клиент-сервер к распределенным Internet-вычислениям.

Oracle8i поставляется в четырех независимых версиях:

• Oracle8I Standart Edition, он же стандартная редакция Oracle8i - базовая версия, включающая в себя основные возможности для большинства Windows NT- и Unix-приложений.
• Oracle8i Enterprise Edition, снабженный дополнительными возможностями для критических OLTP-приложений и хранилищ данных. Эту версию мы и будем рассматривать.
• Oracle8i Personal Edition – однопользовательская система разработки БД для Windows NT, Windows95 или Windows98, включающая в себя все опции и возможности Enterprise Edition.
• Oracle8i Lite – мобильная БД на Java, которая легко синхронизирует БД на портативных компьютерах и palmtop-устройствах с корпоративными БД. Впрочем, она сейчас обсуждаться не будет.

Платформы

Сервер Oracle существует в версиях для более чем 90 платформ. Только их перечисление может занять несколько страниц. Поэтому ограничимся тем, что скажем - имеются версии для основных UNIX-платформ, Windows NT и Windows 9x (Oracle8i Standard и Enterprise Edition может быть установлен только для Windows NT.).

Исторически главная платформа для Oracle - UNIX. Основные UNIX-платформы и сейчас являются для Oracle “операционными системами первой очереди”, то есть теми, для которых новые версии появляются первыми. До сих пор слышатся отголоски тех времен, когда версия для NT считалась уступкой “невзыскательному вкусу части разработчиков”. Некоторые возможности и сейчас доступны только в UNIX-версии.

Различаются и поставляемые средства управления БД. Переход на Java-средства администрирования, уже осуществленный для NT, в случае UNIX объяснимо задерживается - из-за обилия платформ и подходов.

Минимальные и оптимальные характеристики аппаратного обеспечения

Примечание:

• Указанная необходимая емкость жесткого диска включает в себя 15 Мб, которые необходимы для установки Java Runtime Environment (JRE) и Oracle Universal Installer в тот раздел диска, на который установлена операционная система.
• При установке он-лайн документации по Oracle потребуется дополнительно 140 Мб дискового пространства.
• Для установки демонстрационной БД потребуется дополнительно 320 MB места на диске.

1.3. Простота инсталляции

Установка Oracle8i производится с помощью программы, написанной на Java. Мы тестировали версию для Windows NT, но тот факт, что инсталятор написан на Java, дает возможность предполагать, что и на других ОС (естественно, имеющих графический интерфейс пользователя и поддерживающих виртуальную машину Java) применяется эта же программа. Инсталятор Oracle8i даже поддерживает русский язык, но почему-то в самых сложных местах, там где как раз и необходимы коментарии на русском, их нет. Так как ни один SQL-сервер вообще не предлагает интерфейсных программ и инсталяторов на русском, эти мелкие недочеты вполне простительны. Сам инсталятор удобен, лаконичен и позволяет производить как простую установку - новичкам, так и расширенную установку с тонкой настройкой - для профессионалов.

При установке Oracle8i Enterprise Edition for Windows NT, предоставляется возможность выбора одного из следующих вариантов установки:

• Oracle8i Enterprise Edition (со стороны сервера)
• Oracle8i Client
• Oracle Programmer

Выбор при инсталляции варианта “Oracle8i Enterprise Edition” устанавливается сам сервер, необходимые опции (продукты фирмы Oracle можно покупать по частям, такие части и называются “опциями”), и создается и конфигурируется первая БД.

Выбор при инсталляции варианта “Oracle8i Client” позволяет установить на компьютер клиентское ПО, необходимое для соединения с удаленным сервером.

Рис. 1. Программа установки Oracle8i

Выбор же варианта “Oracle Programmer” позволяет установить на компьютер клиентское ПО и дополнительное ПО, необходимое разработчикам: прекомпиляторы, справочную систему и т.п.

При инсталляции сервера можно выбрать один из трех режимов Typical (обычная), Minimal (минимальная) и Custom (выборочная).

Простота первичной настройки

Вопреки расхожему мнению, установка Oracle8i не создала никаких проблем, за исключением того, что некоторые инсталлируемые файлы не были найдены в инсталляционных архивах. Зато при первичной настройке БД появились некоторые проблемы. Так, в поставку Oracle8i больше не входит “Oracle Enterprise Manager” (OEM), хотя в поставку предыдущих версий он входил. Но OEM для Oracle8i все же существует. Его якобы можно скачать с technet.oracle.com, впрочем, не без проблем. Мы, попробовав осуществить это, честно зарегистрировались на сайте Technet и получили пароль - но скачать ОЕМ нам так и не дали, все время демонстрируя сообщение о недоступности данного файла.

Версия 2.0 Oracle Enterprise Manager использует новую трехуровневую модель и основана на Java, что позволяет использовать эту программу не только с Windows NT.

Первый уровень состоит из написанной на Java консоли и интегрированных приложений, инсталлированных или запускаемых из броузера. Администратор может работать с консолью практически из любого места и с любой аппаратной платформы. Компонент среднего уровня - это Oracle Management Server (OMS). Третий слой заключает в себе объекты управления - БД, управляемые сервисы, или цели - БД, узлы, приложения или серверы приложений. Oracle Enterprise Manager - многопользовательский продукт.

OEM может существенно упростить работу администраторов и разработчиков, работающих с Oracle8i. Поэтому попробуйте все же скачать его (вдруг только нам так не повезло), или найдите его предыдущую версию (она постовлялась с Oracle8). Предыдущая версия была реализована для Win32-платформы за несколько лет до появления Oracle8i, но прекрасно работает с ним.

Серьезные проблемы возникли у нас при тестировании Oracle8i с Oracle Developer 6.0. Как это не смешно звучит, но Oracle8i прекрасно взаимодействовал со средствами разработки от Microsoft (Visual Basic, Visual C++, Visual InterDev), но никак не хотел взаимодействовать со средствами разработки собственного производства. Как мы выяснили впоследствии, проблема заключалась в том, что Oracle Developer читал информацию из файлов, устанавливаемых его же инсталлятором, но отличающихся от установленных и сконфигурированных при инсталляции Oracle8i. Это можно обяснить тем, что Oracle Developer 6.0 изначально был сконфигурирован для работы с Oracle версии 8.0.5, в которой файлы настройки сетевого взаимодействия находились в другой директории, нежели в Oracle8i. Путь к этой директории Developer читает из следующего параметра реестра Windows: “HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\NET80”. Для того, чтобы заставить его работать, нам пришлось вручную изменить значение этого параметра на “C:\Oracle\Ora81\NETWORK”, где “C:\Oracle\Ora81” - директория, в которую был установлен Oracle8i. Говоря проще, объяснить, почему средства разработки и сервер одного и того же поставщика не работают друг с другом можно, понять нельзя...

Использование

Администрирование

Количество и качество средств администрирования

В версии 8.1.5 (для Windows NT) на смену старым средствам администрирования и настройки пришли новые - Java-приложения и встраиваемые модули Microsoft Management Console (ММС). Бесспорно, что использование единого интерфейса, уже достаточно знакомого пользователю, облегчает работу. Но в то же время достаточно резкое изменение стиля может вызвать нарекания у опытных пользователей. То, что раньше называлось "менеджерами", стало "ассистентами" - явное понижение в должности. По сути, все ассистенты - не что иное, как Wizard'ы, написанные на Java и выглядящие не то, чтобы лучше, чем у Microsoft, но по своему.

Для Windows 9x и NT теперь доступен “Oracle Administration Assistant for Windows NT” (см. Рис. 2), реализованный также в виде встраиваемого модуля MMC. Это позволяет администратору интегрировать его с другими средствами администрирования, созданными подобным образом или использовать его независимо. К сожалению, спектр возможностей этого средства невелик. С его помощью можно:

Каждая БД запускается под Windows NT как отдельный сервис ОС. Такой сервис можно запускать и останавливать средствами NT, но Oracle Administration Assistant дает некоторую гибкость в этом вопросе. Например, можно выключить экземпляр не сразу, а после отключения последнего пользователя. При этом вход новым пользователям будет запрещен.

Рис. 2. Oracle Administration Assistant for Windows NT

Server Manager

Действия по запуску и остановке экземпляра можно выполнить и из утилиты командной строки Oracle Server Manager (SVRMGRL.EXE).

Server Manager – это утилита, позволяющая пользователю вводить команды в интерактивном режиме.

Возможности Server Manager включают модификацию баз данных и изучение статистики системы, настройку характеристик базы данных, управление защитой и пользователями, восстановление баз данных и выполнение различных действий с файлами, принадлежащими базе данных.

Server Manager поддерживает также пакетный режим (batch mode), предназначенный для выполнения командных файлов. Как правило, пакетный режим используется для выполнения сценария или совокупности команд.

Прямая работа с SQL из консоли

В поставку Oracle входят несколько утилит командной строки, из которых можно производить администрирование БД и работать с данными, кроме того, в поставку входит SQL*Plus. Этому гениальному средству посвящены многочисленные трактаты от разделов документации (причем значительного объема) до глав в больших талмудах типа “Энциклопедии Oracle8”. В них разбираются подходы, применяемые для создания на SQL*Plus отчетов, организации пакетной работы и многое другое. По сути же SQL*Plus - не что иное, как командная строка-переросток. Да, работающая в графическом режиме, поддерживающая печать на Windows-принтеры, имеющая еще много дополнительных возможностей, но все же командная строка.

В прошлой версии (Oracle8) имелся инструмент с названием SQL*Worksheet, который позволял выполнять SQL-запросы, вписывая их в простом текстовом окошке, и выводил результат в таблицу (grid). В Oracle8i эта утилита отсутствует. Дело в том, что из поставки исчез Enterprise Manager, вместе с которым эта утилита и устанавливалась. Возможно, в следующих версиях все вернется на круги своя. Как бы то ни было, большинство пользователей Oracle считало эту утилиту малофункциональной и в своей работе использовало редко. Так что SQL*Plus и является главным средством общения с Oracle8i.

Рис. 3. Средство интерактивного общения с Oracle8i – “SQL*Plus”

Думаю что если бы проводился конкурс на самый неудобный Talker (пакет интерактивного взаимодействия в SQL-сервером) то SQL*Plus занял бы первое место, отобрав лавры у конкурента от InterBase. Зато он практически полностью русифицирован. Представляете себе неопытного пользователя, не знающего английского языка и с удовольствием “долбящего" SQL-запросы из SQL*Plus...

Положительным моментом можно назвать то что в SQL*Plus можно выполнять скрипты на PL\SQL.

Совместимость со стандартами

Oracle8i совместим с минимальным уровнем ANSI/ISO (SQL92). Он поддерживает большинство возможностей, заложенных в более продвинутые уровни SQL92, и даже некоторые из SQL3, но зачастую эти возможности реализованы в нем по своему.

Так, стандарт SQL92 определяет четыре уровня изоляции транзакций. Эти уровни изоляции обусловлены тремя феноменами, которые должны предотвращать взаимное влияние одновременно работающих транзакций.

Перечислим их:

• Dirty read - Транзакция читает данные, которые были записаны другой транзакцией, до подтверждения породившей их транзакцией.
• Nonrepeatable read (fuzzy read) – При повторном чтении данных транзакция обнаруживает данные внесенные и зафиксированные другой транзакцией.
• Phantom read - Транзакция читает данные которых в общем то она не должна учитывать. Например данные добавленные после начала транзакции, и удаленные до окончания этой транзакции. Таким образом появляются строки-фантомы. Такие строки могут негативно повлиять на производимые вычисления, особенно в системах с интенсивным вводом данных.

SQL92 определяет четыре уровня изоляции с точки зрения транзакции, работающей на определенном заданном уровне изоляции.

В Oracle реализованы уровни изоляции read committed и serializable, а так же режим read-only, не являющийся частью SQL92.

Дополнительно надо отметить, что несмотря на совместимость уровня serializable Oracle с SQL92, он все же имеет некоторые отличия. В этом режиме Oracle не производит блокировки записей, что, с одной стороны, ускоряет работу по сравнению с реализациями, блокирующими записи при чтении. Но он не предусматривает семантической идентичности с SQL92, так как этот стандарт подразумевает блокировку данных на все время транзакции. Разработчики приложений могут обойти это несоответствие, применяя выражение SELECT FOR UPDATE. Интересной особенностью Oracle являются т.н. отложенные транзакции, которые позволяют не зависеть от последовательности при модификации данных.

Драйверы

Интерфейсы ODBC, JDBC и OLE

Oracle Call Interface (OCI)

Низкоуровневый интерфейс доступа к БД Oracle для языков C/C++. Поддерживаются все расширенные возможности Oracle8i. Например, поддерживаются массивы, абстрактные типы данных, пакеты и т.п. Работа с этим интерфейсом слишком сложна. К тому же OCI нельзя применять напрямую в языках высокого уровня типа Visual Basic. Поэтому использование его для создания конечных приложений нецелесообразно.

ODBC

Поддерживаются возможности, определенные спецификацией Microsoft ODBC 3.00. Реализованы функции основного (Core), 1-го и 2-го уровней: SQLBrowseConnect, SQLColumnPrivileges, SQLDescribeParam, SQLForeignKeys, SQLMoreResults, SQLPrimaryKeys, SQLProcedureColumns, SQLProcedures, SQLTablePrivileges.

Диалог настройки ODBC (см. Рис. 4) относительно прост и полнофункционален. Практически все опции можно оставить заданными по умолчанию.

Рис. 4. Диалог настройки ODBC

Поддерживается потокобезопасность, что дает возможность использования ODBC-драйвера Oracle в многопоточных серверах приложений.

Однако в силу того, что самыми сильными сторонами Oracle (с точки зрения программиста) являются его нестандартные расширения (массивы, абстрактные типы данных, пакеты...), использование ODBC с Oracle8i приводит к большим неудобствам и потерям производительности по сравнению с родными интерфейсами Oracle.

OLE DB и ADO

Для Oracle8 компанией Microsoft был написан родной OLE DB-провайдер, но с Oracle8i он работать отказался, и, так как ни одна из известных нам организаций не работала с Oracle через этот провайдер, мы решили не его рассматривать. Работать с Oracle через OLE DB-провайдер для ODBC можно, но малоэффективно, поскольку этот провайдер переадресует вызовы непосредственно к ODBC-драйверу (см. раздел ODBC).

Oracle Objects for OLE (OO4O)

OO4O – это средство доступа к БД, базирующееся на COM, позволяющее получать простой, оптимизированный доступ к БД Oracle. OO4O может применяться как в привычных клиент/сервер-приложениях с двухуровневой архитектурой, так и в серверах приложений построенных на основе n-уровневых сред (например, MTS), а так же в Web-серверах. OO4O может использоваться из нового поколения сред программирования, таких как: Visual Basic, Visual C++, Delphi, VBA (Excel, Word), VBScript или JavaScript в IIS Active Server Pages и Internet Explorer.

Всеми отмеченными свойствами обладают такие интерфейсы Microsoft как: ADO, RDO (ODBC) и DAO. Эти интерфейсы более универсальны, они нашли поддержку у большого числа независимых разработчиков, но, к сожалению, не поддерживают большинства расширений Oracle8i, делающих работу с этой РСУБД удобной и производительной. Версия OO4O, входящая в поставку Oracle8i открывает перед разработчиками, реализующими свои проекты в вышеперечисленных средах, простой доступ к всем возможностям предоставляемым БД Oracle.

Вот список самых интересных возможностей доступных через этот интерфейс:

• Полная поддержка координатора транзакций в Microsoft Transaction Server (MTS).
• (Главное) Простой доступ к переменным и объектам специализированных типов данных реализованных в Oracle8i включая:
  • Object References (REFs – ссылочный тип)
  • Object Instances (Objects – объектный тип. По сути аналог структуры в языке C)
  • Nested Tables (Вложенные таблицы)
  • Varrays (Массивы переменной длины)
  • BLOBs, CLOBs, NCLOBs and BFILEs
  • Поддержка параметров типа курсор (это единственный способ возвратить результат выполнения оператора SELECT (Resultset) из PL/SQL-блока или хранимых PL/SQ-процедур).
    Примечание. О типах данных будет рассказано в разделе, посвященном PL/SQL.
• Полный доступ к возможностям Oracle Advanced Queuing.
• Эффективное управление подключениями к БД и пользовательскими сессиями (connection pooling и multiplexing).

Ниже приведен код на VB, демонстрирующий работу с этим API:

Private Sub Command1_Click()
    Text1 = ""
    Dim OraDBSession As OraSession
    Dim EmpDB As OraDatabase
    Dim DS As OraDynaset
    Dim EmpFields As OraFields
    
    Set OraDBSession = CreateObject("OracleInProcServer.XOraSession")
    
    Set EmpDB = OraDBSession.OpenDatabase("TEST_DB", "Scott/tiger", 0)
    Set DS = EmpDB.CreateDynaset("select * from emp", 0)
    Set EmpFields = DS.Fields
    While Not DS.EOF
        Text1 = Text1 & "Name: " & EmpFields("ename").Value _
                  & " ? " & EmpFields("empno").Value & vbCrLf
        DS.MoveNext
    Wend
    
End Sub

Главным недостатком этого API является его реализация. Дело в том, что он написан в так называемом старом стиле. Во времена VB 4 (может быть, я ошибаюсь с точной версией VB, но это не столь важно) Visual Basic поддерживал только Dispatch-интерфейсы. То есть все объекты в нем объявлялись как “Object”, а вызовы к ним производились по имени метода во время выполнения. Говоря проще, производилось позднее связывание. Это уменьшало производительность приложений и приводило к трудностям в разработке (ведь обнаружение ошибок возможно только при непосредственном исполнении ошибочного куска кода). В версии 5 VB стал поддерживать так называемые дуальные (dual) интерфейсы, что дало ему возможность осуществлять раннее связывание (естественно, с контролем типов на стадии компиляции). Сохранилась и возможность работы с объектами типа “Object”, это позволяет работать с Automation-объектами без библиотеки типов, ну и, естественно, позволяет организовать позднее связывание, что увеличивает гибкость. К тому же в VB 5 появилась замечательная возможность “IntelliSense”, она позволяет быстрее писать код, автоматически дополняя частично набранный код или выдавая список применимых объектов, методов, свойств, ..., а также показывая описание методов при их редактировании. Эта возможность работает, только если объект объявлен с конкретным типом (не как Object).

К чему бы все эти отступления от темы? Да к тому, что хотя в библиотеке типов “Oracle InProc Server 3.0” и объявлены все типы объектов, но все методы, их создающие, возвращают тот самый опасный “Object”, и применять расширенные технологии VB 5 становится тяжело и неудобно. В больших проектах это приведет к появлению большого количества ошибок, которых можно было легко избежать, если бы программисты из Oracle удосужились поправить возвращаемые значения методов этого в целом удобного и мощного интерфейса.

Необходимо отметить, что для языка C++ созданы удобные классы-оболочки. Они позволяют C++-программистам работать в привычном стиле, не тратя время на прямую работу с COM-объектами и страхуя от ошибок, связанных с “бестипием”.

Вторым недостатком является то, что OO4O - нестандартный интерфейс и его можно применять, только если вы не собираетесь переносить ваш продукт на отличные от Oracle SQL-серверы.

Самое смешное - Oracle сам наступает на горло собственной песне. Ведь вместо реализации собственного варианта RDO можно было бы внести единственное изменение и разрешить возвращать Resultset’ы из хранимых процедур и PL/SQL-блоков простым вызовом оператора SELECT (как это сделано в Sybase или MS SQL Server). Или, на худой конец, с помощью декларации RETURNS и оператора RETURN в хранимых процедурах (как это сделано в Informix и InterBase). Но у Oracle слишком много денег (по сравнению с Informix, InterBase и Sybase) и слишком мало выпускаемых продуктов (по сравнению с Microsoft), чтобы экономить деньги или время. Поэтому он идет своим путем. На сегодня есть только один способ получить с помощью стандартных интерфейсов (ODBC, ADO, ...) на стороне клиента Resultset, сформированный хранимой процедурой. Это способ состоит из двух этапов: 1) сохранения данных, получаемых в хранимой процедуре, во временной таблице, 2) выборка данных отдельным SQL-запросом (вне хранимой процедуры или PL/SQL-блока). Это решение имеет свои ограничения, связанные с производительностью, но в общем и целом позволяет обходить ограничения, накладываемые стандартными интерфейсами. А ведь всех этих хитростей, можно было бы с легкостью избежать небольшим расширением PL/SQL. И, как следствие, обходиться стандартными ODBC или ADO, не теряя при этом функциональных возможностей, производительности и не усложняя жизнь программистам.

Неправильным путем идете, товарищи!

JDBC

Oracle поддерживает интерфейс взаимодействия с базами данных JDBC (Java Database Connectivity).

Драйверы, реализованные Oracle, имеют несколько реализаций, каждая - со своими особенностями.

JDBC Thin Driver

JDBC Thin driver – это драйвер 4-го типа (т.е. 100% pure Java), использующий для прямого подключения к серверу БД сокеты Java. У этого драйвера есть собственная реализация ТТС (облегченная реализация TCP/IP). Он написан полностью на Java, что делает его полностью платформно-независимым.

Thin driver не нуждается в клиентском программном обеспечении Oracle. Ему нужен только TCP/IP-listener со стороны сервера. Этот драйвер стоит использовать в Java-аплетах, которые загружаются в Web-браузер через интернет. Thin driver является самодостаточным, но поскольку он открывает сокет Java, то работает только с браузерами, поддерживающими использование сокетов. Полная реализация на Java хотя и делает его переносимым, но не лучшим образом сказывается на его производительности.

Драйвер JDBC OCI

Драйвер, основанный на OCI – это драйвер JDBC 2-го типа. Для взаимодействия с сервером БД Oracle он перенаправляет вызовы методов Java вызовам OCI (Oracle Call Interface), реализованным на С.

Поскольку используются прямые низкоуровневые вызовы, драйвер OCI является платформно-зависимым. Ему нужны проинсталлированные драйверы Oracle8i, включая Net8, OCI-библиотеки, CORE-библиотеки и все остальные зависимые файлы. Драйвер OCI работает значительно быстрее, чем Thin driver.

JDBC Server Driver

JDBC Server Driver – это драйвер 2-го типа, работающий на сервере БД. Этот драйвер, виртуальная машина Java на сервере БД, собственный компилятор NCOMP и SQL-engine работают в одном адресном пространстве.

Он позволяет выполнять на сервере любые Java-апплеты, используемые в хранимых процедурах, функциях и триггерах SQLJ, хранимых процедурах Java, объектах CORBA, и EJB (Enterprise Java Beans). Кроме того, имеется возможность вызова хранимых процедур, функций и триггеров PL/SQL.

Драйвер сервера полностью поддерживает те же возможности и расширения, что и клиентские драйверы.

Возможно, представителям Oracle, внушающим всему миру идею о объектной ориентации Oracle8i, лучше больше внимания уделять встроенному, истинно объектно-ориентированному языку программирования, а не рекламировать псевдообъекты (о объектной ориентации речь пойдет в разделе “объектные расширения”).

Расширения стандарта JDBC

Среди всех расширений Oracle для JDBC 1.22, самыми интересными являются:

• Поддержка типов данных Oracle.
• Увеличение быстродействия при помощи предварительной выборки строк.
• Увеличение быстродействия благодаря пакетной работе.
• Определение типов колонок запросов, что уменьшает сетевой обмен.
• Управление вызовами DatabaseMetaData.

Прекомпилятор SQL для Java (SQLJ)

В тесном сотрудничестве с другими фирмами – такими как IBM, Tandem, Sybase и Sun Microsystems, Oracle разработал стандарт встраивания SQL-выражений в Java-программы, названный SQLJ. Этот стандарт зарегистрирован в ANSI под номером x.3.135.10-1998. Пользователь создает приложения, используя этот высокоуровневый API, а затем с помощью препроцессора транслирует программу в стандартный исходный код Java, использующий JDBC-вызовы. Программа может взаимодействовать с БД различных поставщиков, используя стандартные драйверы JDBC. SQLJ можно использовать как с клиентской стороны, так и со стороны сервера. SQLJ может использоваться в хранимых процедурах, триггерах, методах внутри среды JServer, и с EJB и CORBA, кроме того, можно комбинировать SQLJ-программы с JDBC.

Транслятор SQLJ сам создан на Java. Oracle8i содержит так называемый JServer. Поскольку JServer предоставляет завершенное Java-окружение, можно компилировать SQLJ-программы не только на клиенте, но и прямо на сервере.

Расширения

Расширение SQL

В Oracle создан свой язык для создания триггеров, хранимых процедур и просто скриптов (в Oracle их принято называть безымянными блоками). Этот язык получил название PL/SQL (Program Language SQL). PL/SQL – процедурное расширение SQL от Oracle - впервые введено в настольном средстве разработки Oracle Forms. Это так называемый 4GL (язык 4-го поколения). Такие языки в основном разрабатывались в восьмидесятые года. Тогда считалось что 4GL - это следующее поколение языков программирования...но время рассудило по своему, и, похоже, побеждают не 4GL, а наследники 3GL, такие как C++, Java и Basic. Но вернемся к делу. Почему-то хорошие стороны продуктов Oracle все время разбавляются чрезмерно рекламными (часто на грани корректности) высказываниями представителей этой компании. Так, о без сомнения удачном языке - PL/SQL - от специалистов Oracle часто слышно: “Объектно-ориентированный”. Так ли это? Вспомним, что является определяющим в объектно-ориентированной идеологии? Инкапсуляция, Наследование и Полиморфизм. Oracle бесспорно поддерживает первый из этих трех постулатов объектной ориентации. Реализуется это через две особенности PL/SQL: packages (или пакеты, но пакеты звучит больно глупо) и “объектные” типы данных (о не объектной природе объектных типов данных речь пойдет в разделах “Введение новых типов данных” и “Объектные расширения”).

Пакеты позволяют определить общие пакетные переменные и выполнять некоторый инициализирующий код расположенный непосредственно в теле пакета. Также в пакете можно создать набор хранимых процедур для которых будут доступны общие переменные обявленные в теле пакета. Такое же положение и с объектными типами данных. Вроде бы на лицо задатки объектной ориентации? Да, но только очень отдаленные. Объектные типы данных по сути являются не объектными, а скорее расширенными вариантами структур в C или записей в Pascal, так как не поддерживают ни наследования, ни полиморфизма. А package ко всему прочему может существовать только в одном экземпляре. Его нельзя ни явно создать, ни явно уничтожить. Пакет создается , когда пользователь вызывает в первый раз какой-нибудь из его методов, а уничтожается - когда пользователь отключается от сервера или сервер перезагружается. Переменные пакета изолированы (уникальны) для каждого пользовательского подключения, и не могут использоваться для временного хранения общих данных нескольких пользователей. К тому же эти переменные не подчиняются транзакциям, что заставляет инициализировать их при каждом откате БД (по иронии судьбы это иногда бывает даже преимуществом.).

В отсутствие наследования говорить о полиморфизме довольно смешно, ведь независимые объекты не могут менять функциональность друг друга. Отсутствие наследования как на уровне пакетов, так и на уровне объектов, да вообще на любом уровне сводит на нет все объектно-ориентированные преимущества.

Вот и получается, что по сравнению с Oracle8i MS Visual Basic 6.0 является столпом объектно-ориентированного программирования, что уж там говорить про C++ и SmallTalk.

Так что если под объектной ориентацией понимать инкапсуляцию, то C и Pascal (не путать с Borland Object Pascal) придется назвать объектно-ориентированными, ведь в них есть структуры/записи, а указатели на функции с успехом позволят объединить данные и обрабатывающий их код.

А если рассматривать PL/SQL не как объектно-ориентированный язык программирования для создания крутого слоя бизнес логики, а как встроенный язык БД, предназначенный для отслеживания логики данных (целостности и непротиворечивости) то, пожалуй, это один из лучших образцов. Правда не мешало бы добавить в него две возможность возвращать на клиента resultset простым оператором SELECT.

Поддержка же в PL/SQL таких возможностей, как динамические массивы и коллекции объектов под названием VARARRAY позволяет делать процедуры и триггеры очень интеллектуальными.

И все же в задачи нашего журнала входит в обязанность предостеречь программистов, которые хотят реализовывать бизнес-логику силами того или иного SQL-сервера. Сегодня для эти целей лучше использовать серверы приложений. С их помощью возможно создание полноценных приложений на полнофункциональных, заметьте, истинно объектно-ориентированных языках программирования, таких как: C++, Delphi, Java, VB, SmallTalk и даже Prolog. В качестве такого сервера сегодня можно выбрать MTS, если вы приверженец ОС от Microsoft или какую-нибудь из реализаций CORBA, если вас заботит переносимость.

Приверженцам Oracle можно посоветовать обратить внимание на встроенную в Oracle8i поддержку Java (см. “Создание хранимых процедур и триггеров на стандартных языках”).

Пользовательские (хранимые) процедуры и функции

БД Oracle с процедурным расширением (Procedural Database Extension) позволяет хранить и выполнять на сервере процедуры и функции, написанные на PL/SQL. Хранимые процедуры PL/SQL можно вызывать из: других хранимых процедур, триггеров базы данных, безымянных PL/SQL-блоков и практически с помощью любого API (с некоторыми ограничениями), через который можно обращаться к Oracle8i.

В следующем примере показан вызов процедуры order_total, находящейся в пакете order_total, из другой процедуры:

order_total.get_order_total (order_num,status_code, message, merch_gross, shipping. taxes,grand_total);

EXEC SQL
BEGIN
  order_total.get_order_total ( :order_num, :status_code, 
          :message, :merch_gross, :shipping, :grand_total);
END;
END-EXEC;

Из хранимых процедур можно возвращать на клиентскую сторону Resultset'ы, но только с помощью параметра курсорного типа. Такой подход не поддерживается ни одним универсальным API типа ODBC или ADO. Это вынуждает пользоваться специализированными интерфейсами от Oracle (OO4O, OCI) или продуктами, на них основанными (Oracle Forms, Oracle Pro*C, Oracle Pro*COBOL и т.п.). Иначе не удастся использовать расширенных свойств Oracle8i. В простой 2-хуровневой архитектуре отказ от расширенных свойств Oracle приведет к значительному снижению общей производительности из-за усиления нашего врага С.Трафика :-).

В этой ситуации обходным маневром может стать использование сервера приложений, расположенного на той же машине, что и сервер Oracle.

Обыкновенные параметры хранимых процедур могут быть легко получены на клиентской стороне при помощи стандартных API (ODBC, ADO). Исключение составляют, как всегда, нестандартные типы данных, такие, как массивы и объектные типы.

Удобным является то, что методы в packages можно “перегружать”, то есть делать несколько методов с одинаковым именем и разными параметрами. Это позволяет сделать код более читаемым и упростить поиск нужного метода. Как и в других сл    учаях, в пылу рекламного бреда то и дело раздаются заявления, что перегруженные методы, дескать, могут упростить операцию выборки или изменения данных на сервере.

Например: у нас есть таблица TBL1 с тремя полями: F1 INTEGER (PK), F2 DOUBLE и F3 VARCHAR(128). Для удобства модификации данных предлагается создать такое количество одноименных хранимых процедур с такими наборами параметров, чтобы программист не задумываясь вызывал процедуру, а сервер сам подбирал нужную реализацию метода.

CREATE PROCEDURE UPDATE_TBL1(oldF1 IN NUMBER, inF2 IN NUMBER) IS
BEGIN
   UPDATE TBL1 SET F2 = inF2 WHERE F1 = oldF1 
END;
...
CREATE PROCEDURE UPDATE_TBL1(oldF1 IN NUMBER, inF1 IN NUMBER, inF2 IN NUMBER, inF3 VARCHAR(128)) IS
BEGIN
   UPDATE TBL1 SET F2 = inF2, F3 = inF3, F1 = inF1 WHERE F1 = oldF1
END;

Нетрудно посчитать, что количество методов при таком подходе будет резко возрастать при увеличении числа колонок в таблице.

Для универсального изменения конкретных колонок в таблице не надо придумывать велосипед. Проще воспользоваться старым, добрым, но не объектно-ориентированным и не современным оператором UPDATE. С ним не надо изгаляться, создавая бессчетное количество процедур, да и гибкость повыше. А если необходимо защитить данные, то можно вставить защиту в триггер или дать пользователю на растерзание не саму таблицу, а VIEW (представление). Если нужно защитить данные от конкретного пользователя или группы пользователей, просто создайте представление с тем же именем, что и основная таблица, которое будет ограничивать возможности выборки и изменения данных в целевой таблице. Причем дайте пользователю права только на это VIEW, а на саму таблицу прав на просмотр и модификацию не давайте.

Триггеры

PL/SQL используется и для создания триггеров. Для каждой таблицы можно создать до 12 триггеров. Вот шаблон триггера:

CREATE TRIGGER name (событие вызова триггера)...
(необязательное ограничение триггера)
BEGIN
(действие триггepa)
END;

В следующем примере показано создание и использование триггера базы данных.

CREATE TRIGGER check_order_total
AFTER UPDATE OF order_total ON order
FOR EACH ROW
WHEN (new.status = 'NEW')
BEGIN
IF :new.order_total = 0 THEN
INSERT INTO order_log
values(:new.order);
UPDATE order SET :new.status = 'ERR';
END IF;
END;

При определении триггера можно указать, сколько раз он должен выполняться: для каждой изменяемой строки (row trigger), либо однократно для всего выполняемого выражения, независимо от того, сколько строк будет изменено (statement trigger).

Row trigger – Самые часто используемый вид триггера. Выполняются для каждой строки по одному разу. Например, если SQL-выражение UPDATE обновляет множество строк в таблице, то триггер вызывается для каждой строки, которая изменяется выражением UPDATE. Если выражение не влияет ни на одну строку, то триггер вызываться не будет вообще.

Statement trigger – Вызывается независимо от числа измененных строк в таблице, даже если не изменялась ни одна строка. Например, если выражение DELETE удаляет из таблицы несколько строк, триггер уровня выражения DELETE вызывается только единожды, независимо от того, сколько строк удаляется из таблицы.

При определении триггера необходимо указать момент выполнения (trigger timing) тела триггера – до или после выражения. BEFORE и AFTER применимо как к триггерам выражений, так и для строчных триггеров.

Oracle поддерживает еще один тип триггера – INSTEAD-OF. Триггеры INSTEAD-OF доступны только в Enterprise редакции Oracle8i. Они могут использоваться в многотабличных view и в объектных view.

Триггеры INSTEAD-OF предоставляют возможность модификации для view, напрямую не модифицируемых. INSTEAD-OF означает ВМЕСТО. В отличие от других триггеров, Oracle использует эти триггеры вместо выполнения DML-выражений (INSERT, UPDATE и DELETE).

View можно модифицировать как обычную таблицу с помощью INSERT, UPDATE и DELETE, и для соответствующего изменения будет запущен триггер INSTEAD-OF. Триггеры INSTEAD-OF активизируются для каждой изменяемой во view строки.

Модифицирующиеся view традиционно вызывают проблемы неопределенности.

• Удаление строки во view может означать удаление ее из базовой таблицы или такое обновление значений какой-то колонки, при котором она больше не может быть представлена во view.
• Вставка строки во view может означать как вставку строки в базовую таблицу, так и такое обновление значений существующей строки, при котором она уже может быть представлена во view.
• Обновление колонки во view, имеющем связи, может изменить семантику других колонок, не представленных во view.

Объектные view добавляют проблем. Например, частым использованием объектного view является представление связей master/detail. Это неизбежно влечет за собой использование связи, изменение которой, очевидно, приводит к неопределенности.

Результатом этих неопределенностей является множество ограничений, накладывающихся на изменяемые view. Триггер INSTEAD-OF может использоваться в объектных view, также как и в реляционных view, которые не могут быть изменены иным способом.

Даже если view изначально может изменяться, скорее всего, захочется выполнить проверку достоверности значений, которые должны быть вставлены, обновлены или удалены. Триггер INSTEAD-OF может помочь и в этом случае. Приведем код триггера, который выполняет проверку достоверности изменяемых строк и, в случае их достоверности, передает изменение основным таблицам.

Триггеры INSTEAD-OF позволяют модифицировать экземпляры объектных view со стороны клиента через OCI. Для модификации объекта, материализованного объектным view в объектном кэше со стороны клиента и возврата его в постоянное хранилище, следует использовать триггеры INSTEAD-OF. Исключение составляет случай, когда объектный view может модифицироваться изначально. Однако нет необходимости определять эти триггеры только для идентификации и чтения объектного view в объектном кэше.

Для демонстрации возможностей INSTEAD-OF-триггеров создадим view manager_info, который перечисляет всех менеджеров каждого отдела:

CREATE VIEW manager_info AS 
  SELECT d.deptno, d.deptname, e.empno, e.empname 
  FROM   emp e, dept d 
  WHERE  e.empno =  d.manager_num;

Теперь определим триггер INSTEAD-OF, который будет обрабатывать вставку во view. Вставка во view manager_info может быть транслирована в операцию обновления колонки manager_num таблицы dept.

В триггере можно определить ограничение, указывающее, что в отделе, представленном менеджером отдела, должен в данный момент работать по крайней мере один работник.

CREATE TRIGGER manager_info_insert
  INSTEAD OF INSERT ON manager_info 
-- информация о новом менеджере
 REFERENCING NEW AS n 
  FOR EACH ROW
  DECLARE
    empCount NUMBER;
  BEGIN 
    
     /* Первая проверка, выполняется для подтверждения того, что число работников
       отдела больше одного */
     SELECT COUNT(*) INTO empCount 
      FROM emp e
      WHERE e.deptno = :n.deptno;
  
     /* Если работников достаточно, то сделать его (ее) менеджером */
     IF empCount >= 1 THEN

        UPDATE dept d  
         SET manager_num = :n.empno 
         WHERE d.deptno = :n.deptno;

     END IF;
  END; 
  /

Любая вставка во view manager_info, например: 

INSERT INTO manager_info VALUES (200,'Sports',1002,'Jack'); 

приведет к запуску триггера manager_info_insert и обновлению основных таблиц. Подобные триггеры могут выполнять соответствующие действия для view в случаях INSERT и DELETE.

В Oracle8i также поддерживаются триггеры системных и пользовательских событий.

Каналы (Pipes)

Пакет DBMS_PIPE позволяет общаться двум и более сессиям, работающим с одной базой данных. Каналы (pipes) Oracle схожи по концепции с каналами, используемыми в UNIX, но каналы Oracle реализуются без использования механизма каналов операционной системы.

Информация, передаваемая через каналы Oracle, буферизуется в глобальной системной области памяти (system global area – SGA). Вся содержащаяся в каналах информация теряется при закрытии базы данных.

В зависимости от требований безопасности можно использовать каналы public (общие) или private (частные).

Предупреждение: Каналы не зависят от транзакций и могут повлиять на контроль над ними.

Public Каналы

Public каналы можно создать явно или неявно. Неявные public-каналы автоматически создаются при первой ссылке на них, и исчезают, если более не содержат данных. Явный public-канал создается вызовом функции CREATE_PIPE с private-флагом, установленным в FALSE. Удалять явно заданные каналы придется вызовом функции REMOVE_PIPE.

Все public-каналы работают асинхронно. Любое количество пользователей может писать в общий канал, если им дано право EXECUTE на пакет DBMS_PIPE, и они знают название общего канала. Однако буферизованная информация удаляется из буфера после считывания первым пользователем, и недоступна для других пользователей канала.

Сессия, отправляющая данные, создает сообщение, используя один или более вызовов процедуры PACK_MESSAGE. Эта процедура добавляет сообщение к буферу локальных сообщений сессии. Информация этого буфера отсылается вызовом функции SEND_MESSAGE с назначением имени канала, используемого для посылки сообщения. При вызове SEND_MESSAGE отправляются все хранящиеся в локальном буфере сообщения.

Процесс, желающий получать сообщения, вызывает функцию RECEIVE_MESSAGE, передавая в качестве параметра имя канала, используемого для получения сообщений. Затем процесс вызывает процедуру UNPACK_MESSAGE для доступа к содержанию сообщения.

Частные, или Private-каналы

Private-каналы создаются явно вызовом функции CREATE_PIPE. Будучи созданными, private-каналы существуют в разделяемой памяти вплоть до явного их удаления функцией REMOVE_PIPE. Private-каналы также уничтожаются при закрытии базы данных.

Private-канал не может быть создан, если в памяти существует неявный канал с тем же именем. В этом случае CREATE_PIPE возвращает ошибку.

Доступ к private-каналам имеют только:

Попытка передачи/приема данных по такому каналу, или же попытка его удаления, предпринятая любым другим пользователем, вернет ошибку, как и попытка создания канала с таким же именем.

Посылка и прием сообщений осуществляются так же, как и по общим каналам.

Использование каналов

Приведем несколько примеров использования каналов:

• Интерфейс с пользовательскими сервисами, внешними по отношению к СУБД. Это может быть многопотоковое взаимодействие, с одновременным исполнением нескольких экземпляров сервиса. В дополнение, сервисы доступны асинхронно. Сервис может быть создан на любом из поддерживаемых 3GL-языков.
• Независимые транзакции: канал может связываться с отдельной сессией, которая может выполнять операции в независимой транзакции (например, запись о попытке нарушения защиты, обнаруженной триггером).
• Отладка: триггеры и хранимые процедуры могут посылать отладочную информацию через каналы. Другая сессия может выводить эту информацию на экран или записывать в файл, считывая ее из канала.
• Концентратор: полезно при мультиплексировании большого числа пользователей через малое количество сетевых подключений, или улучшении производительности концентрированием нескольких пользовательских транзакций в одну транзакцию СУБД.

Вложенные таблицы

Вы можете создать таблицу с колонкой, тип данных которой является другой таблицей. Это означает, что таблицы могут быть вложены в другие таблицы наподобие значений в колонках. Сервер Oracle хранит данные вложенных таблиц вне строк родительской. Родительская строка содержит уникальный идентификатор, ассоциированный с экземпляром вложенной таблицы.

Временные таблицы

В дополнение к постоянным таблицам, Oracle может создавать временные таблицы для хранения данных сессии, существующие только в течение данной сессии или транзакции.

Команда CREATE GLOBAL TEMPORARY TABLE создает временную таблицу для конкретной сессии или транзакции. Данные временных таблиц принадлежат конкретной сессии и не могут быть доступны другой. Команда LOCK не влияет на временные таблицы, поскольку для каждой сессии создается своя копия

Индексы для временных таблиц создаются командой CREATE INDEX и являются столь же временными, как и данные временных таблиц.

Временные таблицы можно использовать при создании view. В одном view можно совмещать как временные, так и постоянные таблицы.

Index-Organized Tables

Index-Organized Tables (IOT) отличаются от обычных таблиц тем, что данные таблицы хранятся в ассоциированном с ней индексе. Изменения данных таблицы, например, добавление или изменение строк, выливаются только в изменения индекса. Вместо хранения идентификатора строки в качестве второго элемента вхождения индекса хранятся собственно данные строки. Приложения работают с IOT так же, как и с обычными таблицами. В некоторых случаях это ускоряет работу и уменьшает объем хранящихся данных.

Переносимые табличные пространства (tablespaces)

Эта возможность позволяет пользователю переносить информацию из одной БД Oracle в другую. Это - как бы отключение некоего раздела от одной БД и его подключение к другой. Кроме того, возможно копирование tablespace между БД. При таком копировании могут переноситься и индексные данные, и их не придется создавать заново, как при импорте или загрузке табличных данных.

View

Oracle8i обеспечивает расширенную функциональность по отношению к view. В нем поддерживаются так называемые объектные view, специальные триггеры INSTEAD-OF (взамен..., см. раздел триггеры) и материализованные view (Materialized view).

Самое интересное из этих расширений - материализованные view.

Материализованные view

Материализованное view - это view, результаты которого не вычисляются в момент обращения к нему с помощью оператора SELECT, а хранятся в специальных скрытых от пользователя таблицах. В Oracle и раньше была подобная возможность. Она называлась SNAPSHOT. Главным отличием SNAPSHOT в прошлой версии Oracle от материализованных view является то, что последние могут автоматически обновляться при изменении базовых таблиц. Материализованные view позволяют заметно ускорить обработку аналитических и статистических запросов, производящих агрегатные вычисления над большими объемами данных. Самое интересное, что Oracle автоматически преобразовывает запросы к базовым таблицам так, чтобы использовать агрегированные значения из материализованных view, тем самым значительно повышая производительность. Таким образом, вы можете повышать производительность давно эксплуатируемых приложений простым добавлением материализованных view, ведь они даже не будут знать, что вычисления производятся не над базовыми таблицами.

Для создания материализованного view используется выражение CREATE MATERIALIZED VIEW. Это выражение содержит подзапрос, обычно связь или агрегацию данных (GROUP BY), результаты которого входят в материализованное view.

Материализованное view обслуживается процессом обновления. Этот процесс может выполняться автоматически при фиксации операции, либо может контролироваться вручную администратором БД. Обновление view может выполняться как полностью, так и только для измененных данных.

Материализованные view - это объекты схемы, которые используются для обобщения, прекомпиляции, репликации и распределении данных. Они могут использоваться в широком диапазоне вычислительных сред - хранении данных, поддержке принятия решений и в распределенной или мобильной среде.

Материализованные view чем-то напоминают индексы: используют область хранения, должны обновляться при изменении данных в главных таблицах, и при использовании для преобразования запросов, увеличивают скорость обработки SQL-запросов. Кроме того. В отличие от индексов, к материализованным view можно получить доступ напрямую в выражении SELECT и, в зависимости от типа обновления, в выражениях INSERT, UPDATE или DELETE.

В целом материализованные view - полезное новшество, облегчающее жизнь разработчика и позволяющее оптимизировать некоторые аспекты работы с базой данных. Не следует, тем не менее, считать это нововведение некой палочкой-выручалочкой. Материализованным view присущи ограничения, вытекающие из жизненных реалий - поскольку даже такому гиганту как Oracle не по силам сделать все и сразу. Приведем их краткое перечисление, позаимствованное из документации Oracle8i.

• Запрос на котором базируется материализованное view не может выбирать данные из таблиц или view, принадлежащих пользователю SYS.
• В запросе, на котором базируется материализованное view, нельзя использовать выражение ORDER BY.
• Материализованные view не могут базироваться на индексных таблицах (index-organized tables), если в запросе, на котором базируется материализованное view, содержатся связи или оператор GROUP BY.
• Материализованные view не могут содержать колонок с типом данных LONG.
• Если подзапрос ссылается на временную таблицу, для этого материализованного view нельзя ни создать log, ни указать QUERY REWRITE в CREATE MATERIALIZED VIEW или в ALTER MATERIALIZED VIEW.
• Если в списке FROM материализованного view есть ссылка на другой материализованное view, то, чтобы сохранить целостность, следует отследить порядок обновления материализованных view вручную.
• Подзапрос не может содержать (напрямую либо через view) ссылок на ROWNUM, USER, SYSDATE, удаленные таблицы, последовательности или функции PL/SQL, которые могут записывать или считывать БД или package.
• Материализованные view и базовые таблицы должны быть локальными
• Нельзя использовать условия HAVING или CONNECT BY.
• В материализованном view нельзя определять любые вложенные подзапросы или вложенные (inline) view.
• При использовании GROUP BY, в нем нельзя использовать функции или выражения PL/SQL, и, кроме того, в списке SELECT следует определить все колонки GROUP BY.
• Все реляционные объекты, представленные в списке FROM, должны быть таблицами, причем они должны отличаться после разрешения синонимов.
• Для комплексных материализованных view следует определить внешние связи, и перечислить обе стороны этих связей в списке GROUP BY.
• Каждое агрегированное выходное выражение должно использовать только одну функцию агрегации (SUM, MIN, MAX, COUNT(x), COUNT(*), COUNT(DISTINCT x), AVG, VARIANCE, GROUPING или STDDEV) с выражением, которое содержит неявную ссылку на любую другую группирующую функцию.

Приведем примеры использования материализованных view.

Следующее выражение создает и заполняет материализованное view, а также определяет режим и время обновления:

CREATE MATERIALIZED VIEW mv1 REFRESH FAST ON COMMIT
   AS SELECT t.month, p.prod_name, SUM(f.sales) AS sum_sales
      FROM time t, product p, fact f
      WHERE f.curDate = t.curDate AND f.item = p.item
      GROUP BY t.month, p.prod_name
   BUILD IMMEDIATE;

В следующем выражении создается и заполняется материализованное view SALES_BY_MONTH_BY_STATE. Материализованное view будет заполнен данными после успешного выполнения выражения, а последующие обновления будут осуществляться повторным выполнением запроса материализованного view.

CREATE MATERIALIZED VIEW sales_by_month_by_state
   TABLESPACE my_ts PARALLEL (10) 
   ENABLE QUERY REWRITE
   BUILD IMMEDIATE
   REFRESH COMPLETE
   AS SELECT t.month, g.state, SUM(sales) AS sum_sales
      FROM fact f, time t, geog g
      WHERE f.cur_date = t.cur_date AND f.city_id = g.city_id
      GROUP BY month, state;

В следующем выражении создается материализованное view MJV на базе запроса, построенного из нескольких связанных между собой таблиц. Такой подход позволяет ускорить выполнение запросов, но взамен требует дополнительного места на диске и замедляет вставку в основные таблицы.

CREATE MATERIALIZED VIEW mjv
   REFRESH FAST
   START WITH 1-JUL-98
   NEXT SYSDATE +7 AS
      SELECT l.rowid as l_rid, l.pk, l.ofk, l.c1, l.c2,
         o.rowid as o_rid, o.pk, o.cfk, o.c1, o.c2,
         c.rowid as c_rid, c.pd, c.c1, c.c2
      FROM l, o, c
      WHERE l.ofk = o.pk(+) AND o.ofk = c.pk(+);

Внешние процедуры и функции

Напомню, что в контексте нашего “Внешняя процедура” – некоторая подпрограмма, написанная на любом внешнем (не встроенном в сервер) языке програмирования, оформленная в виде отдельного исполняемого модуля (например DLL или EXE для Win32), которую можно динамически подключить к серверу и вызывать отдельным вызовом из хранимых процедур, триггеров.

“Внешняя функция” – то же самое, что и внешняя процедура, но может вызываться непосредственно из SQL-запроса, как встроенная функция.

В Oracle реализованы как внешние процедуры, так и внешние функции.

Внешней процедурой в Oracle является подпрограмма, хранимая в DLL, или метод элемента библиотеки Java-класса.

Oracle предоставляет возможность создавать внешние процедуры на следующих языках:

• PL/SQL
• C/C++, с использованием Oracle Call Interface (OCI) или прекомпилятора Pro*C/C++.
• COBOL, с использованием прекомпилятора Pro*COBOL.
• Visual Basic, с использованием Oracle Objects For OLE (OO4O).
• Java, с использованием JDBC Application Programmers Interlace (API).

Можно использовать и другие языки, создающие динамически подключаемые библиотеки или Java-апплеты.

С точки зрения быстродействия важно помнить, что только методы PL/SQL и Java работают в адресном пространстве сервера. Методы C и C++ рассматриваются как внешние процедуры и работают на сервере, но вне пределов его адресного пространства. Pro*COBOL и Pro*C являются прекомпиляторами, а Visual Basic получает доступ к Oracle через OCI (опосредованно, через OO4O), реализованный на C.

PL/SQL и Java являются интерпретаторами со всеми вытекающими отсюда последствиями. Так что если вам надо выполнить сложные ресурсоемкие расчеты не требующие частого взаимодействия с сервером БД или вам нужен прямой доступ к низкоуровневым библиотекам, то лучшим будет выбор C/C++, COBOL или Visual Basic, в противном случае лучше воспользоваться PL/SQL или Java.

В предыдущих версиях внешние процедуры приходилось регистрировать в Oracle с помощью выражения AS EXTERNAL во wrapper’е, реализованном на PL/SQL. В Oracle8i появились спецификации вызова, которые включают в себя оболочку AS EXTERNAL как часть нового оператора AS LANGUAGE. Теперь спецификации вызова AS LANGUAGE позволяют выполнять регистрацию не только внешних процедур С, как раньше, но и методы Java-классов.

Вызывать внешние процедуры и функции лучше всего из PL/SQL-процедур и PL/SQL-функций, которые должны предварительно зарегистрировать данную внешнюю процедуру. Подобным образом зарегистрированную подпрограмму можно вызывать из:

• Безымянных PL/SQL-блоков
• Одиночных PL/SQ-процедур и PL/SQL-процедур инкапсулированных в пакете.
• Методов объектных типов.
• Триггеров БД.
• SQL-выражений (только при вызове подпрограмм, упакованных в PL/SQL-функции).

Создание хранимых процедур и триггеров на стандартных языках

Самой интересная для разработчиков возможность из предлагаемых сегодня Oracle - это реализация хранимых процедур и триггеров на Java.

Перенос Java-приложения на сервер

Для взаимодействия с Java на сервере в Oracle8i используется JServer.

JServer – это серверная Java платформа, она включает в себя:

• Виртуальную машину Java “Oracle Aurora”.
• Runtime-среду Java.
• Библиотеки классов Java.
• Object Request Broker (Aurora/ORB)

JServer обеспечивает поддержку:

• Enterprise JavaBeans.
• интеграцию с PL/SQL.
• SQLJ и JDBC.

Виртуальная машина Java выполняет Java-программы прямо на сервере Oracle8i.

Сегодня существующие приложения в основном используют PL/SQL. Oracle8i позволяет коренным образом изменить эту ситуацию. Он позволяет создавать на Java хранимые процедуры, триггеры и Object Type-методы, вызывать PL/SQL-программы из Java и Java- программы из PL/SQL.

В дополнение к поддержке хранимых процедур традиционных реляционных СУБД, JServer поставляется со встроенным CORBA 2.0-совместимым ORB (Inprise VisiBroker for Java версии 3.2) поддерживающим Enterprise JavaBeans (EJB). ORB позволяет программам, разработанным на различных языках связываться с БД Oracle8i по протоколу Internet-Inter-ORB Protocol (IIOP). CORBA и EJB дают возможность распределять компоненты Java и логику приложения между клиентом, промежуточным уровнем и сервером БД.

Действия, которые необходимо предпринять для переноса существующего приложения написанного с использованием SQLJ или JDBC на сервер, довольно просты и незатейливы. Вот шаги которые надо предпринять для переноса приложения, которое уже транслировано на клиенте:

1. Приложение необходимо поместить в файл .jar-архива.
2. Загрузить .jar- файл на сервер утилитой loadjava.
3. Создать SQL-wrapper для своего приложения на сервере. Например, чтобы выполнить приложение MyExample на сервере надо выполнить следующий PL/SQL скрипт:

create or replace procedure SQLJ_MYEXAMPLE as language java 
name 'MyExample.main(java.lang.String[])';

После этого можно выполнять SQLJ_MYEXAMPLE как любую другую хранимую процедуру.

Взаимодействие Java с PL/SQL

Все драйверы Oracle JDBC бесшовно связываются с Oracle SQL и PL/SQL. Можно параллельно использовать SQLJ-процедуры и хранимые процедуры, написанные на PL/SQL. Oracle SQLJ содержит синтаксис для вызова хранимых процедур PL/SQL и, кроме того, позволяет выполнять анонимные блоки PL/SQL, так же, как и SQL-операторы. Единственное, что остается понять - зачем это делать? Ведь Java код будет транслирован в байт-сод, а анонимные блоки PL/SQL сохранятся как строки и будут разбираться и интерпретироваться при каждом выполнении.

Возможность использовать в запросе внешние источники данных

Oracle8i позволяет подключаться к другим серверам Oracle с помощью встроенных средств.

Для использования источников данных, отличных от БД Oracle можно воспользоваться одним из описанных выше программных API, но использовать совместно (в одном запросе БД Oracle) и эти данные не удастся.

Введение новых типов данных и объектные расширения

Здесь Oracle впереди планеты всей. В версии 8.0 были введены так называемые объектные типы данных. Такие типы данных можно применять при создании локальных и пакетных переменных, при объявлении колонок БД и даже при объявлении строк (вернее, типа записи) в таблицах БД. Причем в случае, когда объект олицетворяет всю запись целиком в качестве первичного ключа, точнее вместо него, используется так называемая объектная ссылка (REF). REF является вполне самостоятельным типом данных и может использоваться для ссылки на такую объектную запись из других таблиц.

Операторы создания объектного типа очень похож на операторы создания пакетов. Вот как они выглядят:

CREATE TYPE Complex AS OBJECT ( 
-- Атрибуты
   rpart REAL,
   ipart REAL,
-- Описание методов
   MEMBER FUNCTION plus (x Complex) RETURN Complex,
   MEMBER FUNCTION less (x Complex) RETURN Complex,
   MEMBER FUNCTION times (x Complex) RETURN Complex,
   MEMBER FUNCTION divby (x Complex) RETURN Complex
);

CREATE TYPE BODY Complex AS 
-- Реализация методов
   MEMBER FUNCTION plus (x Complex) RETURN Complex
   IS
   BEGIN
      RETURN Complex(rpart + x.rpart, ipart + x.ipart);
   END plus;

   MEMBER FUNCTION less (x Complex) RETURN Complex
   IS
   BEGIN
      RETURN Complex(rpart - x.rpart, 
                     ipart - x.ipart);
   END less;

   MEMBER FUNCTION times (x Complex) RETURN Complex
   IS
   BEGIN
      RETURN Complex(rpart * x.rpart - ipart 
       * x.ipart, rpart * x.ipart + ipart * x.rpart);
   END times;
   MEMBER FUNCTION divby (x Complex) RETURN Complex
   IS
      z REAL := x.rpart**2 + x.ipart**2;
   BEGIN
      RETURN Complex((rpart * x.rpart + ipart * x.ipart) / z,
                     (ipart * x.rpart - rpart * x.ipart) / z);
   END divby;
END;

Вся эта красота входит в полное противоречие со стандартными представлениями о реляционной модели, описанной Коддом еще в 70-е. Самое смешное, что с точки зрения математического описания модели, да и просто с точки зрения гибкости реализация Oracle уступает стандартной реляционной модели. Зато по простоте восприятия простым человеком она превосходит реляционную модель.

К примеру, представьте таблицу курсов валют Rate. Она состоит из полей: RateDate DATE – дата курса, RateCurrency INTEGER – тип валюты, и Rate FLOAT – сам курс. В такой таблице логично не вводить специальный первичный ключ (PK), а объявить его состоящим из двух полей - RateDate и RateCurrency. Такое решение позволит автоматически перенести входящие в PK поля во все таблицы, ссылающиеся на таблицу курсов. То есть в таблице проводок (таблице, в которой регистрируются финансовые операции) необходимо только сделать ссылку (создать внешний ключ) и добавить собственно поля, необходимые для описания транзакции. Если реализовать эту задачу в стиле Oracle, то для получения данных о времени совершения сделки или о валюте сделки придется каждый раз обращаться к таблице курсов или создавать псевдоколонки с ручной синхронизацией данных, так как объектные таблицы вместо РК используют REF. Это в свою очередь может привести к ошибкам в целостности данных, что явится обратным по отношению к благой цели преследуемой использования объектных расширений.

После всего сказанного злой шуткой может прозвучать, что объекты в Oracle8 имеют отдаленное отношения к объектно-ориентированной идеологии. Как и в случае packages объекты поддерживают только инкапсуляцию, но не поддерживают не наследования, не полиморфизма.

В общем и целом введение в Oracle объектов, несомненно, серьезный шаг. Вот только непонятно - в правильном ли направлении?

По моему, если уж и вводить объектную ориентацию, так уж надо делать это продуманно и полностью, а не самыми простыми кусками. Похоже, что самым правильным путем в этом направлении пошел Informix. В свое время он попросту купил компанию Illustra, которая уже несколько лет создавала одноименную чисто объектно-ориентированную БД.

Если же говорить о том, что лично я жду от объектно-ориентированной БД, то это полная замена реляционной идеологии описания “мира” в терминах сущность-отношение на объектно-ориентированное описание в терминах наследования, включения и связей между объектами. Немаловажным является и переопределение поведения (реакции на внешние события) у классов-наследников, по-научному, полиморфизм. Да и все-таки классов, а не объектов. Господа, не повторяйте ошибок Borland’а! Все-таки класс и экземпляр класса - понятия намного более определенные, чем термин объект, который больше похож на описание экземпляра, а не класса.

Для СУБД главное - объектная ориентация в таблицах БД, а не создание еще одного ОО языка программирования.

Представьте, как удобно было бы работать, если мы объявили таблицу - нет, в объектно-ориентированном стиле не таблицу, а список (collection) - “персона”. Потом унаследовали от него “покупателя” и “служащего”, а от служащего унаследовали “продавца” и “управляющего”. А теперь представьте, что нам дают создать не методы (фу, скучно), а объектно-ориентированные агрегатные функции. Причем в классах-потомках можно изменять поведение таких функций, да еще так, чтобы не переписывать весь код этих функций, а только дописав или запретив необходимые условия. Теперь представьте, что для всей этой красоты не пришлось создавать новых таблиц, пардон, списков, а новые типы легко добавляются в runtime’е. Каково, а? Лично у меня дух захватывает. Ну ладно, последний штрих, а то совсем размечтался. При выборках и подсчетах агрегатов можно использовать не занудные логические операторы (хотя и они должны остаться), а чтобы можно было просто написать “WHERE INHERITED FROM “служащий” AND ...”. Вот это я понимаю - объектная ориентация в БД.

А чем изучать объектные зачатки встроенных языков БД с целью найти лучшую реализацию для описания бизнес-логики, проще один раз освоить какой-нибудь сервер приложений и выбрать какой-нибудь мощный и современный язык программирования из имеющихся в изобилии.

Хранение же и обработка блобов, по моему, вообще не дело SQL-сервера (с этим можно поспорить - прим. ред.) - их проще хранить в обыкновенных файлах. Тогда не придется с помпой объявлять, а потом мучительно дописывать специальное ПО эмуляции файлов на базе таблицы БД. В БД проще хранить только информацию о файлах и ссылки на физические файлы, которые, к слову, могут быть распределены хоть по всему земному шару. В Oracle еще в версии 8.0 был введен тип "ссылка на файл", но почему-то пиары этой компании забыли раздуть из этого мощную рекламную компанию. Единственное, чего не хватает в Oracle для полной реализации этой идеи - полнотекстовой индексации внешних файлов. Но это можно реализовать с помощью внешних индекс-серверов, хотя, конечно, было бы удобно иметь такую возможность в SQL-сервере.

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

Объектные расширения, несомненно, присутствуют в Oracle8i. Ситуация с ними очень похоже на ситуацию из старого анекдота: “Сообщение по радио в передаче милицейская хроника: "Граждане, будьте осторожны! В магазинах появились поддельные елочные игрушки. Они выглядят как настоящие, но радости от них никакой...”.

Отладка хранимых процедур и триггеров

В состав Oracle8i не входят специальные программы, предназначенные для отладки хранимых процедур и триггеров, но такую программу можно бесплатно скачать с www.oracle.com/st/products/features/plsql.html.

Этот отладчик, написанный на Java. Он может запускаться как в качестве апплета из броузеров Microsoft или Netscape, так и как отдельная программа. Отладчик работает с Oracle 7.3.4 и выше. Этот отладчик можно применять и при создании Web-приложений на PL/SQL, работающих с Applications Server.

С Oracle8i поставляется API DBMS_DEBUG, служащий для отладки серверных приложений на языке PL/SQL. На сегодняшний день существует несколько отладчиков, использующих этот API, например, Oracle Procedure Builder, а также несколько решений от сторонних разработчиков.

Oracle Procedure Builder позволяет запускать PL/SQL-процедуры и триггеры в контролируемой отладочной среде, устанавливать breakpoints и так далее.

Хранимые процедуры и триггеры можно отлаживать и с помощью поставляемого пакета DBMS_OUTPUT - вводя в код утверждения PUT и PUT_LINE для вывода на экран значений переменных и выражений.

Триггеры отлаживаются с помощью тех же средств, что и хранимые процедуры.

Средства разработки

Как вы уже наверное догадались, большую часть средств поддержки Java на клиентской машине Oracle позаимствовал у Inprise. Oracle лицензировал JBuilder у Inprise, назвав его JDeveloper (на серверной стороне используется Inprise VisiBroker). Однако в дальнейшем пути этих изначально схожих продуктов стали расходиться. В этом продукте оптимизировано взаимодействие с БД Oracle. Так что несомненно его можно считать лучшим продуктом для Java-разработчиков.

Среди средств разработки, базирующихся на 3GL-языках, тоже можно порекомендовать продукты от Inprise. Такие как Delphi и C++Builder. Они поддерживают многие из расширений Oracle. Те, кто предпочитает продукты от Microsoft, могут смело пользоваться Visual C++, но приготовьтесь к тому, что некоторая расширенная функциональность Oracle не будет доступна.

Среди 4GL: Power Builder, Centura/Gupta Team Developer, Microsoft Visual Basic, Oracle Developer.

Предпочтения кому-либо здесь отдать трудно, так как у каждого продукта есть свои сильные и слабые стороны.

Связь с серверами приложений и другими продуктами

В поставку Oracle8i Enterprise Edition уже входит сервер приложений (о нем говорилось ранее). Также Oracle можно использовать (в том числе и обыкновенную редакцию) с серверами приложений от независимых поставщиков. Например MTS или VisiBroker.

Устойчивость к аварийным ситуациям

За все время тестирования Oracle ни разу не зависал и не вылетал. О надежности Oracle говорит и большое количество пользователей во всем мире. У Oracle есть большая служба поддержки, но ее услуги стоят серьезных денег. Заплатив за высшую степень поддержки, вы можете получить личного представителя компании в свое распоряжение и неограниченную круглосуточную поддержку.

Поддержка русского языка

Поддержка национальных языков, а русского, как наиболее нам дорогого - в особенности, является одной из сильных сторон Oracle. Oracle может работать практически со всеми раскладками кириллицы, вплоть до самых экзотичных.

Средство поддержки национального языка Oracle (National Language Support – NLS) позволяет пользователям вести работу с базами данных не только на их родном языке, но и на нескольких языках одновременно. Оно поддерживает различные схемы кодирования. Это значит, что данные, созданные в схеме кодирования на одном компьютере, могут быть обработаны и представлены на другом, с другой локалью. Вы определяете символьный набор, который будет использоваться для хранения данных в базе, как часть оператора CREATE DATABASE. Например, данные, созданные в базе данных с ASCII 7-битовым стандартным символьным набором для США, могут быть выведены на дисплей компьютера, подключенного к той же базе данных, но использующего набор символов Chinese GB2312-8. Таблицы трансляции системы поддержки национального языка обеспечивают это преобразование. Соответственно изменяется язык вывода ошибок сервера и информационных сообщений, чисел, дат, денежной единицы и начального дня недели, а поддержка лингвистической сортировки гарантирует, что символы появляются в нужном порядке.

Определение языка NLS осуществляется как для базы данных в целом, так и на уровне сеанса. Изменяя параметры сеанса и не внося изменений в учетную запись пользователя Oracle, вы могли бы выполнять одни сеансы на английском языке, другие на немецком и т.д., если одно имя пользователя Oracle соединено с базой данных через несколько различных сеансов.

Можно добавлять поддержку новых языков, используя программный продукт NLS*WorkBench.

Oracle работает над программным продуктом автоматического перевода сообщений, выдаваемых пользователю.

Количество пользователей версий и цены на лицензии

Oracle, несомненно, продукт бесценный. С нами в представительстве Oracle с удовольствием говорили на любую тему, кроме цен. Самым замечательным было заявление о том, что "каждый пользователь у нас получает индивидуальную скидку" без всякого упоминания о начальной цене. Объяснить, почему цены являются секретными данными, невозможно. Но будучи людьми настойчивыми, мы все-таки выяснили примерные цены на Oracle.

Oracle - один из немногих программных продуктов, дорожающих со временем. Не далее, как в августе этого года Oracle поднял цену на Oracle8i на 125$, потом снизил цену на 100$ (теперь клиентская лицензия стоит 395$ вместо 370$). Правда, техническая поддержка подешевела на 30$, но уверены ли вы, что хотите оплачивать техническую поддержку для всех без исключения пользователей Oracle?

Все, что связано с Oracle, вообще обходится крайне недешево. Например, Oracle Developer 6.0 стоит 7495$ - а каждая дополнительная клиентская лицензия еще 200$, а более серьезный набор средств разработки Oracle Enterprise Development Suite - 12495$ на одного разработчика (стоимость техподдержки 4750$).

В заключение

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

Так уж сложилось, что и Oracle, и Microsoft хотят видит друг друга в качестве конкурентов на рынке РСУБД и рынке серверов приложений. Причем обе фирмы в упор не хотят замечать других конкурентов. До этого обзора я не как не мог понять, почему Oracle начиная с 1998 года проявляет такую неподдельную ревность к продуктам от Microsoft, и почему все сравнения и испытания нацелены на доказательство превосходства именно над Microsoft? С другой стороны непонятно, почему во всех публикациях в качеств конкурента MS SQL Server выступает только Oracle? Для наглядности взгляните на следующую таблицу.

Наверное, думал я, тут играет роль то, что и Microsoft и Oracle являются крупнейшими фирмами среди производителей ПО. Со стороны Microsoft такое положение вещей можно было бы объяснить тем, что Oracle – всеми признанный лидер на рынке РСУБД, и Microsoft хочет равняться только на лидера.

Хотя рано подводить итоги, мы еще не опубликовали обзоры по двум главным конкурентам в этой среде – по Informix и Sybase - но уже сейчас можно сказать, что большинство серверов можно с успехом применять везде, где требуется надежный и производительный сервер БД. Причем разница в производительности у фаворитов при испытаниях на PC не превышает 5-7 раз, уж точно не как в заявлениях Oracle - сотни раз. Причем недостаток в одной области обычно компенсируется превосходством в другом.

Так почему же именно Microsoft vs. Oracle? Теперь, после пристального изучения Oracle, я могу попытаться дать ответ на этот вопрос и обосновать его.

Технологии управления БД с применением реляционной модели, кажется, подходят к совершенству. Поэтому становится все трудней повышать производительность путем введения более оптимальных алгоритмов. С другой стороны, аппаратное обеспечение стремительно развивается, и сегодня на PC (ну, правда, не совсем простом) можно создавать терабайтные БД. Причем скорость их обработки потрясает, а от сервера БД не требуется никакой дополнительной функциональности (все делается аппаратно)!

Исходя из вышесказанного нетрудно понять, что конкуренция плавно переходит от сравнения мускулов к сравнению умственных способностей. Главные девизы наших дней: даешь логику на сервере, даешь Internet, даешь асинхронную и распределенную работу...

Microsoft и Oracle хотя и проповедуют совершенно разную с технической точки зрения идеологию, но кое-что общее у них есть. Причем это "кое-что" выливается в большие деньги. Попробуем проанализировать шаги Oracle в последнее время:

• Raw Iron – переход СУБД к работе без ОС.
• Интеграция компонентов, несвойственных для SQL-сервера, таких как организация очередей сообщений и встраивание полнофункциональных серверов приложений.
• Встраивание в СУБД файловой системы.
• Поддержка компонентов и катриджей.
• Есть даже информация о том, что Oracle ведет работы над прямой поддержкой сервером HTTP-протокола.

Не правда ли, этот набор скорее характерен для ОС, чем для СУБД? А вот тут то собачку и зарыли. ОС-ы - это главная статья доходов Microsoft. В свою очередь Microsoft планомерно и с завидным постоянством вводит в Windows NT/2000, все новые и новые сетевые средства и средства “серверной автоматизации”. Вот набор, который войдет в поставку Windows 2000 (W2K).

• MSMQ (Cервер очередей сообщений)
• Component Services (Он же COM+, он же MTS.) Сервер приложений, позволяющий создавать удаленно работающие приложения, поддерживает:
• Компонентную архитектуру.
• Транзакции.
• Асинхронное взаимодействие (через MSMQ).
• Событийный механизм (COM+ Event Services).
• В поставку специализированной версии W2K (Так называемую Data Center Edition) будет входить MS SQL Server.

Сравните эти два списка. Ну чем не общий конкурентный рынок?

Несомненно, Oracle это мощный и полнофункциональный продукт, но в борьбе с Microsoft еще никто не побеждал. У Oracle есть и силы и средства для такой борьбы. Так что нам еще предстоит лицезреть битву титанов. Но первый бой Oracle, похоже, проиграл. Его вызов в $1 000 000 с заявлением о 100-кратном превосходстве Oracle8i над MS SQL Server был парирован Microsoft - однако результаты этого тестирования не были сертифицированы TPC. Вообще, в этом сравнении много неясностей. И та, и другая сторона охотно комментируют результаты тестирования, опровергая друга – но официальные заявления обеих сторон довольно расплывчаты. Microsoft более открытая и «пропагандистская» фирма. В ее руках такие козыри, как исходные коды Windows NT и более агресивный (причем очень грамотный) маркетинг.

Похоже, противостояние Oracle vs Microsoft - это всерьез и надолго. Так что нам с вами прийдется выбирать между БД, поглощающей всю компьютерную индустрию и все пожирающей ОС.

Copyright © 1994-2016 ООО "К-Пресс"