嗨 甲骨文【5】

对象类型

 

看此章节之前，让我联想起JDO。如果Oracle能把关系型数据库的操作以对象为单位实现，那该有多好。不知这一章将带给我什么。
 

对象组件包括属性和方法

属性是Attribute的翻译。通常在高级语言里，属性通常是Property的翻译，而Attribute被译为特征。在Oracle里，Attribute和java里的Property是对应的。即拥有描述对象所具有的属性。

 

方法（ Method ）用于实现对象所执行的操作。

1构造方法在9i后，允许重载了.

CONSTRUCTOR FUNCTION fangfaming(somevariable...)
RETURN SELF AS RESULT
这里的fangfaming必须是定义的类名，不然还叫什么“构造子”了

2MEMBER方法就是高级语言里的实例方法,

MEMBER PROCEDURE fangfa1 ()

MEMBER FUNCTION fangfa2() RETURN simple_type

使用：

DECLARE

a_shili a_lei;

BEGIN

a_shili.fangfa1()

3STATIC方法就是类方法，全局方法。

A_lei.staticfangfa();

4MAP方法用于将对象实例映射为标量数值,然后根据该标量类型数据可以排序对象实例。用于比较多个对象实例。

5ORDER方法用于比较两个对象实例的大小

在一个对象类型中，只能定义一个MAP方法或者一个ORDER方法（它们不能同时使用）。  

 

对象类型

包括对象类型规范(Object Type Specification)和对象类型体(Object Type Body)。就是定义和实现部分。对于熟悉delphi的人，也许会认为这样的方式才显得很得体。

建立对象类型规范的语法：

CREATE OR REPLACE TYPE type_name AS OBJECT(

       Attribute1 datatype,[,attribute2 datatype,…],

       [MEMBER|STATIC method1 spec,

MEMBER|STATIC method2 spec,…]);

建立对象类型体的语法：

CREATE OR REPLACE TYPE BODY type_name AS

       MEMBER|STATIC method1 body;

       MEMBER|STATIC method2 body;

…]);

建立对象类型时，至少定义一个属性，可以不定义方法（这是不需要建立对象类型体）。

 

对象表--就象高级语言里的对象/实例，是对类的实现，分为行对象和列对象

行对象是直接给予对象类型所建立的表

CREATE TABLE table_name OF type_name

列对象是包含多个列的对象表

CREATE TBALE table_name{

       Mynum number(6),

       Mytype type_name,

       Mychar varchar2(10)

);

 

REF数据类型

通过REF应用行对象，何以是不同的表共享相同的对象，从而降低了内存的占用。

下面是Jdo的相关信息。作者sun2bin

Oracle与JDO
作为JDO专家组的重要成员，同时作为最大的关系数据库厂商的Oracle地位显然非同一般。在JDO规范中，Oracle也可说是立下汗马功劳，很多API的形成，Oracle都提供了很重要的参考意见，最终的投票Oracle也是毫不犹豫。
可是，世间的事总是变化莫测的，就在JDO1.0快出台之时，Oracle收购了TopLink，这一点使Oracle的身份变得特殊而复杂。TopLink是一个商业产品，是以商业利益为目标的，而Oracle也是追求利益最大化的典型商家，这一点与JDO的开放精神背道而驰。因此，我们看到后期Oracle对JDO的不积极态度，甚至在前一阵的JavaOne大会上有人从Oracle的角度非正式地攻击JDO。--《 JDO之前世今生》

对象包装技术，百家争鸣？群魔乱舞？
于是，从规范化开发的原则出发，我们开始写自己的JavaBean来包装数据对象，使数据对象化，避免太多的地方涉及JDBC操作。但一些问题也随之而来：灵活性不够，接口死板，性能低下，这使我一阵苦恼。于是，“君子性非异也，善假于物也”，咱也上网去找点“技术支持”！很快，竟然被我发现了“Castor JDO”，一个专用于数据包装的撞阕榧峁┝薕DMG标准的OQL作为查询语言，方便且容易理解，比SQL好多了。这让我享受了一段时间的“面向对象的数据库开发”的好处，一句话，“效果不错，还实惠！”。

然而，好景不长，Castor一些内在的BUG影响了稳定性，而这个免费产品的更新又太慢，一直未能解决。只好放弃。“执手相看泪眼，竟无语凝噎”！怎么办？要知道，由俭入奢易，由奢入俭难，吃过肉的人，怎能忍受只能吃菜的生活！象《甲方乙方》里面那个一心想吃素的大款还是不多见的。对我们来说，再使用JDBC原始调用似乎难以下咽，再用JavaBean包装又有点返古，于是我又开始了网上的搜寻历程。 余秋雨 先生有《文化苦旅》，咱这也算是《编程苦旅》了，呵呵，苦笑。

从网上的资料来看，我的这些经历也是很多Java开发同仁的共同经历，无论是国内还是国外，不过从实际情况来看，国外的研究更深入更广泛一些，至少从网上所能找到的资料来说是这样。美国从八十年代起就开始研究面向对象的数据库ODBMS，目前已有一些成形的产品，比如Versant公司的Versant数据库，FastObjects公司的FastObjects t7数据库，以及其它一些相对市场份额小一些的诸如ObjectStore等公司的产品，当然，也不乏一些免费的产品，如Orient等等。总的来说，ODBMS尽管拥有面向对象的优点，但由于历史原因，在与关系数据库RDBMS的竞争中始终处于下风，基于RDBMS的应用还是占绝大多数，因此，出现了Object-Relational映射的一些工具，前面提到的Castor就是近年来出现的一个工具，实际上更早的时候，已经有一些成熟、稳定的商业化产品出现，比如前一阵被Oracle收购的TopLink，被BEA收购的WebGain等等，比较有名气的CocoBase等等。

象TopLink这样的产品我也了解了一下，功能确实强大，性能、稳定性都有优势，然而，其同样强大的价格和古怪的API令我却步。我很担心被锁定在某个产品上面，无法脱身，众所周知，Java给我们的就是一种自由的感觉，自由，永远是那么地吸引人。

出路在哪里？JDO浮现在我眼前。

JDO自1999年起就由一些经常写数据库对象映射层的富有经验的开发人员提出大纲，他们在长期的面向对象开发中进行了大量的数据库方面的处理和对象化包装，终于，多种多样的包装方式引起很多兼容性方面的问题。于是，一些主要的开发团队就联合起来，以SUN为领头羊，制定了JDO规范。它的目标不是取代JDBC或EJB，而是在JDBC的基础上进行包装，同时又可以做EJB的底层（CMP），简化J2EE服务器提供商的工作。JDO主要面向中小型规模的项目，不过随着产品提供商（Vendors）给出越来越多的功能（Feature），比如分布式的同步控制等等，JDO的作用也越来越大。JDO规范在Sun的富有经验的Craig Russel的带领下，经过三年的讨论，在2002年四月形成了第一版。--《如何用JDO开发数据库应用》