Oracle对象有多广泛使用?

10

我正在为数据库课程写作业,我们需要将现有关系模式迁移到Oracle对象上。这整个过程让我想知道,这些东西实际上有多广泛地使用?数据模型不稳定,语法可怕,而且对象导向只实现了大约四分之三。

有人真的会使用这个吗?

8个回答

14

首先,一些标准的Oracle功能使用类型,例如XMLDB和Spatial(其中包括声明Nested Table数据类型的列)。

此外,许多PL/SQL开发人员经常使用类型,用于声明PL/SQL集合或管道函数。

但我同意,很少有地方广泛使用类型并构建基于PL/SQL的API。这有几个原因。

  1. Oracle缓慢地实现了对象功能。虽然它们在8.0版本中引入,但直到9.2版本才完全支持继承、多态和用户定义的构造函数。没有这些功能,正确的面向对象编程是不可能的。我们在11g版本中才获得了SUPER()。即使现在还有一些缺失的功能,其中最明显的是TYPE BODY中的私有声明。
  2. 语法通常很笨重或令人沮丧地晦涩。文档也没有帮助。
  3. 大多数与Oracle工作的人倾向于来自关系/过程式编程学派。这意味着他们倾向于不理解面向对象编程,或者他们未能理解它在数据库编程中的有用性。即使人们想出一个好主意,他们也会发现使用Oracle的语法很难或不可能实现。

最后一点是关键。我们可以学习新的语法,我们可以说服Oracle完成功能集,但只有在我们能够用类型解决问题时才值得使用它们。这意味着我们需要找到可以使用继承和多态性解决的问题。

我曾经参与过一个广泛使用类型的系统开发。那是一个数据仓库系统,数据加载子系统是由类型构建的。其基本原理很简单:

  • 我们需要为每个加载的表应用相同的业务规则模板,因此该过程是通用的;
  • 每个表都有自己的投影,因此SQL语句对于每个表都是唯一的。

类型实现干净简洁:通用过程定义在Type中;每个表的实现定义在继承自该通用Type的Type中。具体类型可以从元数据生成。我在几年前的UKOUG上介绍了这个主题,并在我的博客上详细介绍了它。 了解更多信息。

顺便说一下,关系理论包括域的概念,这是用户定义的数据类型,包括约束等。没有任何RDBMS支持域,但Oracle的类型实现绝对是一个步骤。


2
另一个缺点是客户端通常无法处理Oracle对象。例如,ODP.NET(用于将Oracle与.NET应用程序连接的Oracle提供程序)长时间不支持Oracle类型。这使得使用空间数据变得困难。这在2007年12月已经改变了。 - TTT
1
我曾以类似的方式使用过这个功能——我们为数据仓库开发了一个定制的ETL引擎。每个数据处理步骤都是抽象步骤的子类(提供像日志记录和强制执行公共接口之类的通用内容),具体步骤存储实际的SQL逻辑(并在XML中存储自定义配置,因为它经常是动态生成的)。引擎本身不知道给定步骤应该做什么——它只是调用每个步骤的执行方法。采用这种方法的另一个原因之一是我们不知道未来的步骤类将是什么。 - miazo

10

我从未看到它的好处,主要是因为上次检查时,一旦对象被表使用,它们的定义就是不可变的。

所以如果您在客户表定义中使用了一个地址对象,那么您将无法更改Address对象的定义,除非删除Customer表,或者经历非常复杂的转换过程。

对象适用于数据实例化,例如应用程序执行的操作,但是对于数据存储和基于集合的操作,我根本看不出有什么意义。


7
许多其他回答已经给出了使用对象的好例子; 一般来说,这些是为了处理某些特定的、可能比较复杂的数据类型。Oracle本身就用它们来处理地理空间数据。
除了一些大学课程中可能会出现的情况之外,使用基于对象的表来存储像员工和部门之类的常规数据是不常见的,像这样:
create type emp_t as object (empno number, ename varchar2(10), ...);
create table emp of emp_t;

虽然这些可能是用来教授概念的不错的简单示例,但我担心它们可能会导致一代新的数据库开发人员认为这种方法既适合,又更现代,因此比“老式”的关系表更好。但实际上并不是这样。


2
+1,感谢您在表定义中使用对象的问题上提出了明确的观点。即使将对象类型用于列也是不必要的。我特别喜欢“它绝对不是这样的”这句话。 - DCookie

5

我只听说过它在一个地方被使用,而且涉及的开发人员正在转换以摆脱它。我曾考虑纯粹在PL/SQL中使用它,但由于我们的DBA不允许我们安装任何类型,因为他们担心我们可能会在表中使用它们,所以这是不可能发生的。

分享并享受。


3

在系统中看到它们扮演一个小角色并不太罕见。例如,如果你正在处理Oracle数据插件,有时需要它们来完成一些奇怪的任务。

但是,在系统中广泛使用它们是不常见的。我曾经见过两个不同的系统大量使用对象,结果都很糟糕:难以使用、非常缓慢,而且充满了bug。

“简单”的关系方法使用基本的表格、行和列几乎总是足够好的。每个程序员(和程序)都可以理解这些概念,并且它们足够强大,可以完成几乎任何任务。然而,你可能需要花费多年时间来完全理解和优化这些方法。对象关系技术增加了大量复杂性,但收益却很少。


3
我使用了简单类型的构造函数和一些方法来封装与现有TCP服务器交互的功能。我需要传递x个字节(原始对象),并接收回x个字节(清洁对象)。我本可以编写一些特定于我的任务的过程,但使用对象类型使其更具通用性。没有什么花哨的东西,非常基本的面向对象的东西,创建原始对象,填充其100多个属性中的一小部分,调用其清理函数,并将结果分配给一个新的“干净”对象。任何其他想要调用TCP服务器的人都可以遵循相同的基本步骤,只需使用其数据填充任何原始值即可。
然而,在我的经验中,我不认为Oracle是面向对象的,而是具有一些基本的对象功能。正如其他人所说,公司不会因为它的面向对象能力而购买Oracle。在我看来,不要对Oracle太过纠结。

2

我必须说,人们购买Oracle并不是因为它。它非常不可移植/非标准化,正如Adam指出的那样,还存在一些使用上的陷阱。我个人没有看到它的好处。我不知道它的使用有多广泛,但我无法想象它很大。浏览一下这个网站,看看有多少问题是关于它的。这可能会给你一些见解。


1

我从未在我的实践中使用过它们,也从未听说过有人使用它们,我猜它们并不被广泛使用。如果你有一个面向对象的数据库,这很重要,Oracle 支持 OO 但不是 OO 数据库。我认为从 OO 数据库迁移到 Oracle 的人会广泛使用它们。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接