Картридж клиента

Картридж сервера приложений

Картридж данных

ный эжений

Универсальный сервер

Рис 2 1 Архитектура сетевых вычислений (NCA) Oracle

Вероятно, еще более интересна для проектировщиков (которые ищут, как удовлетворить сложные требования к серверу в среде Oracle) возможность использовать PL/SQL-вызовы для выполнения запросов к другому картриджу Этот механизм к моменту написания книги был соверщенно нов, и у нас не было возможности построить что-нибудь с его помощью. Но кажется, что он предоставляет гибкий метод вызова любого картриджа из Oracle. Традиционно эти возможности проектирования были ограничены вызовом других экземпляров Oracle средствами SQL или PL/SQL и обращениями к другим СУБД через прозрачные щлюзовые сервисы Oracle.

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

Об OracleS

Многие специалисты по Oracle ожидали, что Oracle анонсирует OracleS на объединенной конференции Oracle Open World и International Oracle User Group в Сан-Франциско в ноябре 1996 г., однако представители корпорации сделали на этой конференции очень мало официальных заявлении о содержании OracleS и времени ее выхода в свет. Oracle подтвердила, что у ряда клиентов и партнеров имеются бета-версии. Однако мы знаем, что промышленная версия программы может заметно отличаться от бета-версий (которые также могут существовать в различных вариациях). Редко, но бывает, что уже

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

Эти замечания могут оказаться особенно важными в отнощении OracleS, которая содержит новые функции, нацеленные главным образом на поддержку гораздо больщих баз данных по сравнению с нынещними. Кроме того, все давно ждут, что в новой версии будет реализована некоторая поддержка объектной ориентации (00) в SQL.

Секционирование

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

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

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

Совместтиостъ с Oracle?

Единственная серьезная потенциальная проблема совместимости, о которой мы в настоящее время знаем, - это то, что формат идентификатора строки изменился настолько, что сейчас, по сути, есть две его фо]щы. Краткая форма - это все, что нужно для ссылки на строку именованное таблицы, а длинная форма позволяет однозначно идентифицировать любую строку в базе данных.

Несмотря на то, что эти изменения почти наверняка сделают бесполезными больщое количество скриптов, написанных администраторами БД,

лишь немногие приложения основываются на внутренней структуре идентификатора строки. Краткая форма (которой вполне хватает для SELECT R.OWID...FOR UPDATE) умещается в 18 байтах, которые должны были выделяться для старой формы. Хотелось бы отметить, что все приложения, использующие внутренний формат идентификатора строки, не заслуживают переноса в Огас1е8.

Но...

Повторим то, что мы сказали в начале этого небольшого раздела, посвященного Огас!е8: хотя эти и многие другие возможности, на первый взгляд, выглядят очень привлекательно, перед тем как принимать решение об использовании их в проекте, нужно предпринять целый ряд мер. Как минимум, применять их в приложении промышленного уровня можно лишь после того, как Oracle введет их в промышленную версию. Кроме того, для адекватного прогнозирования результатов их использования компьютерная индустрия должна накопить опыт работы с этими средствами в реальных условиях.

Что сказать о материале по Oracle?, который содержится в этой книге? Устареет ли он с выходом Огас1е8? Нам кажется, что ненужным станет лишь незначительная его часть. Надеемся, впрочем, что новые возможности помогут найти новые решения для ваших проблем проектирования.