我正在为数据库课程写作业,我们需要将现有关系模式迁移到Oracle对象上。这整个过程让我想知道,这些东西实际上有多广泛地使用?数据模型不稳定,语法可怕,而且对象导向只实现了大约四分之三。
有人真的会使用这个吗?
我正在为数据库课程写作业,我们需要将现有关系模式迁移到Oracle对象上。这整个过程让我想知道,这些东西实际上有多广泛地使用?数据模型不稳定,语法可怕,而且对象导向只实现了大约四分之三。
有人真的会使用这个吗?
首先,一些标准的Oracle功能使用类型,例如XMLDB和Spatial(其中包括声明Nested Table数据类型的列)。
此外,许多PL/SQL开发人员经常使用类型,用于声明PL/SQL集合或管道函数。
但我同意,很少有地方广泛使用类型并构建基于PL/SQL的API。这有几个原因。
SUPER()
。即使现在还有一些缺失的功能,其中最明显的是TYPE BODY中的私有声明。最后一点是关键。我们可以学习新的语法,我们可以说服Oracle完成功能集,但只有在我们能够用类型解决问题时才值得使用它们。这意味着我们需要找到可以使用继承和多态性解决的问题。
我曾经参与过一个广泛使用类型的系统开发。那是一个数据仓库系统,数据加载子系统是由类型构建的。其基本原理很简单:
类型实现干净简洁:通用过程定义在Type中;每个表的实现定义在继承自该通用Type的Type中。具体类型可以从元数据生成。我在几年前的UKOUG上介绍了这个主题,并在我的博客上详细介绍了它。 了解更多信息。
顺便说一下,关系理论包括域的概念,这是用户定义的数据类型,包括约束等。没有任何RDBMS支持域,但Oracle的类型实现绝对是一个步骤。
我从未看到它的好处,主要是因为上次检查时,一旦对象被表使用,它们的定义就是不可变的。
所以如果您在客户表定义中使用了一个地址对象,那么您将无法更改Address对象的定义,除非删除Customer表,或者经历非常复杂的转换过程。
对象适用于数据实例化,例如应用程序执行的操作,但是对于数据存储和基于集合的操作,我根本看不出有什么意义。
create type emp_t as object (empno number, ename varchar2(10), ...);
create table emp of emp_t;
虽然这些可能是用来教授概念的不错的简单示例,但我担心它们可能会导致一代新的数据库开发人员认为这种方法既适合,又更现代,因此比“老式”的关系表更好。但实际上并不是这样。
我只听说过它在一个地方被使用,而且涉及的开发人员正在转换以摆脱它。我曾考虑纯粹在PL/SQL中使用它,但由于我们的DBA不允许我们安装任何类型,因为他们担心我们可能会在表中使用它们,所以这是不可能发生的。
分享并享受。
在系统中看到它们扮演一个小角色并不太罕见。例如,如果你正在处理Oracle数据插件,有时需要它们来完成一些奇怪的任务。
但是,在系统中广泛使用它们是不常见的。我曾经见过两个不同的系统大量使用对象,结果都很糟糕:难以使用、非常缓慢,而且充满了bug。
“简单”的关系方法使用基本的表格、行和列几乎总是足够好的。每个程序员(和程序)都可以理解这些概念,并且它们足够强大,可以完成几乎任何任务。然而,你可能需要花费多年时间来完全理解和优化这些方法。对象关系技术增加了大量复杂性,但收益却很少。
我必须说,人们购买Oracle并不是因为它。它非常不可移植/非标准化,正如Adam指出的那样,还存在一些使用上的陷阱。我个人没有看到它的好处。我不知道它的使用有多广泛,但我无法想象它很大。浏览一下这个网站,看看有多少问题是关于它的。这可能会给你一些见解。
我从未在我的实践中使用过它们,也从未听说过有人使用它们,我猜它们并不被广泛使用。如果你有一个面向对象的数据库,这很重要,Oracle 支持 OO 但不是 OO 数据库。我认为从 OO 数据库迁移到 Oracle 的人会广泛使用它们。