Насколько широко используются объекты Oracle?

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

Кто-нибудь действительно использует это?

Ответ 1

Для начала некоторые стандартные функциональные возможности Oracle используют типы, например XMLDB и Spatial (включая объявление столбцов типов данных вложенной таблицы).

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

Но я согласен, что в нескольких местах широко используются типы и выстраиваются из них API PL/SQL. Для этого есть несколько причин.

  • Oracle реализовал объекты очень медленно. Хотя они были представлены в версии 8.0, только до 9.2 они полностью поддерживали Наследование, Полиморфизм и пользовательские конструкторы. Надлежащее объектно-ориентированное программирование невозможно без этих функций. Мы не получили SUPER() до версии 11g. Даже сейчас есть недостающие функции, особенно частные объявления в TYPE BODY.
  • Синтаксис часто неуклюжий или расплывчатый. Документация не помогает.
  • Большинство людей, работающих с Oracle, как правило, исходят из реляционной/процедурной школы программирования. Это означает, что они не понимают ООП или не понимают, где это может быть полезно при программировании базы данных. Даже когда люди придумывают опрятную идею, им трудно или невозможно реализовать с использованием синтаксиса Oracle.

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

Я работал над одной системой, которая широко использовала типы. Это была система хранилища данных, и подсистема загрузки данных была построена из типов. Основополагающее обоснование было простым:

  • нам нужно применить один и тот же шаблон бизнес-правила для каждой загружаемой таблицы, поэтому процесс является общим;
  • каждая таблица имеет свою собственную проекцию, поэтому операторы SQL уникальны для каждого.

Реализация типа чиста: общий тип определяется в типе; реализация для каждой таблицы определяется в типе, который наследуется от этого родового типа. Конкретные типы могут генерироваться из метаданных. Я представил эту тему в UKOUG несколько лет назад, и я написал ее более подробно в своем блоге. Узнайте больше.

Кстати, Relational Theory включает концепцию Domains, которые являются определяемыми пользователем типами данных, включая ограничения и т.д. Никакой вкус RDBMS фактически не поддерживает домены, а реализация типа Oracle определенно является шагом на этом пути.

Ответ 2

Я никогда не видел выгоды для этого, главным образом потому, что, когда я в последний раз его изучал, ваши определения объектов были неизменными, как только они были использованы таблицей.

Итак, если у вас был объект Address, который вы использовали в определении таблицы Customer, вы никогда не сможете изменить определение объекта Address, не отбрасывая таблицу Customer или не переходя через очень выигрышное преобразование.

Объекты прекрасны для создания данных - как и то, что делает приложение, но для хранения данных и манипуляций на основе набора, ну, я просто не вижу смысла.

Ответ 3

Многие из других ответов дали хорошие примеры того, где использование объектов имеет смысл; в целом они предназначены для обработки некоторых, возможно, сложных типов данных. Сам Oracle использует их для геопространственных данных.

Что обычно не, за исключением того, что это было бы грустно появляться в некоторых учебных заведениях колледжа, заключается в использовании объектных таблиц вместо обычных реляционных таблиц для хранения регулярных данных, таких как сотрудники и отделы, примерно так:

create type emp_t as object (empno number, ename varchar2(10), ...);
create table emp of emp_t;

Хотя это могут быть хорошие простые примеры для обучения концепциям, я боюсь, что они могут привести к созданию нового поколения разработчиков баз данных, которые считают этот подход подходящим, более современным и, следовательно, лучше, чем "старомодные" реляционные таблицы. Это категорически не так.

Ответ 4

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

Поделитесь и наслаждайтесь.

Ответ 5

Не слишком необычно видеть, как они играют небольшую роль где-то в вашей системе. Например, если вы что-то делаете с картриджем данных Oracle. Иногда, когда вам нужно делать что-то действительно странное, они необходимы.

Необычно видеть, как они широко используются в системе. Я видел, что две разные системы используют множество объектов, и это было катастрофой одновременно: сложно использовать, очень медленно и полно ошибок.

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

Ответ 6

Я использовал простые типы с конструкторами и несколько методов для переноса некоторых функций взаимодействия с существующим tcp-сервером. Мне нужно было передать x байты (необработанный объект) и получить обратно x байты (чистый объект). Я мог бы написать некоторую процедуру, которая была бы особенно для моей задачи, но использование типа объекта позволило сделать это более общим для других. Ничего необычного, очень базового материала OO, не создавайте необработанный объект, не заполняйте несколько его 100 или около того свойств, не вызывайте его чистую функцию и не назначайте результат на новый "чистый" объект. Любой, кто хотел вызвать сервер tcp, мог следовать одним и тем же основным шагам, только заполняя все необработанные значения своими данными.

Тем не менее, по моему опыту, я бы не сказал, что Oracle является объектно-ориентированным, а скорее имеет некоторые базовые функциональные возможности объектов. И, как утверждают другие, компании не покупают Oracle для своих возможностей OO. Не слишком увлекайтесь им с помощью Oracle imo.

Ответ 7

Я бы сказал, что это не то, почему люди покупают Oracle. Это очень не-портативный/нестандартный, и, как указал Адам, есть и некоторые ловушки использования. Я лично не видел этой выгоды. Я не знаю, насколько широко распространено это использование, но я не могу себе представить, что он очень большой. Осмотрите этот сайт, чтобы узнать, сколько вопросов задают об этом. Это может дать вам некоторое представление.

Ответ 8

Хорошо, никогда не использовал их в своей практике, никогда не слышал, чтобы кто-нибудь их использовал, а не широко используется. Думаю, имеет значение, когда у вас есть объектно-ориентированная база данных, oracle поддерживает OO, но не является базой OO. Я думаю, что люди, которые мигрируют из OO-баз данных в Oracle, используют их широко