
иметь идеальная объектно-ориентированная база данных, будет в книге об объектно-реляционной СУБД не к месту.
OracleS, возможно, не удовлетворит объектно-ориентированных пуристов, но разве это так важно? OracleS все равно построена на базе реляционной модели. Любой шаг в сторону объектной модели будет медленной метаморфозой и не помешает пользователям, которые рады остаться в реляционном мире. Движение Oracle в направлении объектной технологии более очевидно в ее архитектуре сетевых вычислений (NCA), которая позволяет пользователям подключать картриджи (по замыслу очень похожие на апплеты) к базе данных или клиентскому приложению.
Мы не против объектов, честное слово. Мы не против Oracle. Просто та поддержка объектов, которую мы видели и смогли испытать в OracleS, на текущий момент как-то не получается. Нельзя сказать, что OracleS нас огорчила. Проблема инструментального средства вторична, и, как мы уже говорили, мы не видим причины, по которой объектно-ориентированное приложение не могло бы использовать структурированную, декомпозированную память в качестве своего хранилища данных. Если мы получим постоянную память с:
•	подклассами;
•	наследованием;
•	динамическим полиморфизмом;
•    способностью описывать декларативные ограничения целостности для атрибутов объектных типов;
•   способностью задавать функции-конструкторы;
•    вызовом функций-конструкторов по умолчанию (возможно),
то будем очень заинтересованы в использовании этих возможностей в
проектах.
Сейчас мы не имеем планов использования объектных средств OracleS в своих проектах. Вместе с тем, мы полагаем, что найдем применение большим объектам (LOB) для хранения данных, структуру которых не нужно определять в словаре.данных Oracle. В некоторых случаях мы также собираемся использовать пакет DBMS_LOB (см. главу 4) для организации процедурного доступа к структурам внутри LOB.
110	Oracle 8