ORM其实是在映射网络模型和关系模型,OO的关系模型无需映射,且更简单高效

O-R Mapping 从字面上理解是在 面向对象体系 与 关系数据库 之间进行映射.

不过最近为了写 TOB 的 ORK 模型资料, 更进一步研究了 Entity-Relationship 模型以及相关的 网络模型, 关系模型 和 Entity Set 模型. 然后有个惊人的发现:

  ORM 所支持的 POJO 模型本质上其实是网络模型, 而 O-R 的 Mapping 其实是在 网络模型 和 关系模型之间进行映射.

--有了这个发现, 总算对一直以来对 ORM 和 POJO 模型的一些感性的抵触有了一个理性的认识.

认定 ORM 所支持的 POJO 模型为 网络模型, 判断如下:

1. 对象之间的关联是通过 单边(Unidirectional)或者对等(Bidirectional)的引用(Reference)或者引用集合(Reference Set)建立起来的. 没有独立的 Relationship 载体.
2. 对等(Bidirectional)的引用或引用集合之间也存在不自然的单向性, 其中必有一方为 Owner, 而另一方为 Member. 这是网络模型的特有特征.

而关系模型下 实体 之间的关联是通过独立的 关系记录 代表的, 而 关系记录 上也可以有自己的属性, 很多情况下这些 关系属性 非常重要, 使关系模型能够比网络模型更接近现实世界的结构. 比如一辆汽车的组装模型, 用到某种型号的螺母, 而这种螺母的单车用量, 作为 车型 与 螺母型号 两个实体之间的 关系属性 才最为恰当.


人们一直认为 关系模型 与 面向对象体系 之间无法完美融合, 也遭遇了多方面的尝试失败, 但是以目前我的研究分析结果来看, 这其中的根本原因是大家还没有认识到这些失败的研究和尝试仅只是在用 面向对象的方法 去实现 网络模型 的持久数据管理系统.

目前成熟的面向对象数据库, 比如为 Java 和 .Net 设计的 db4o http://www.db4o.com 其实是网络数据库. 通用面向对象程序设计语言 (General Purpose Object Oriented Programming Language), 特别是广泛应用的一些, 像 C++, Java 方面, 始终没有本土的关系模型数据库出现. 而应用程序开发领域广泛采用了这些 通用面向对象程序设计语言, 并且难以割舍.

加上 Hibernate 所引领的层出不穷的 ORM 框架产品, 呈现给人一种感觉, 那就是, 面向对象 与 关系模型 水火不容, 只能 Mapping.

但是事实上, 众多传统关系数据库产品早已加入了面向对象的思想特性, 称为 Object Relational Database http://en.wikipedia.org/wiki/Object-relational_database, 像 Oracle 8 以后就是. 更有甚者比如 InterSystems 的 CACHÉ http://www.intersystems.com/cache/index.html, 自称为 Post-Relational Database, 而其实已经可以通过完全的面向对象的语言来进行数据库开发, 只不过用的是自家(Home Grown)的OO语言.

而通用OO语言一直没能融合关系模型的一个根本原因, 是大家总是拒绝向内存对象模型引入 "关系对象" 的概念, 而这是 关系模型 区别于 网络模型 的根本特征之一.

不过在传统的以磁盘为主体存储的数据库系统中, "关系对象" 所建立起来的 "关联" 自然而然的完全存在于逻辑上, 这同时也使得对 "关联" 的操作非常简单, 只有3件事:

1. 创建关系对象以建立关联
2. 删除关系对象以解除关联
3. 指定 JOIN 以引用关联

这里的 3, 限定了对关系数据的访问只能是通过 SQL, 一种不可能 OO 的语言.

目前的数据库市场仍然还是 以磁盘为主体(Disk Targeted) 的数据库产品的天下, 所以天经地义的, 关系模型与 SQL 之间, 在人们心里存在一个等号.

但是随着64位计算的日趋普及, 大内存也成为趋势, 于是现在已经出现了新的可能:
  在内存里建立关系模型的对象数据!
而基于日趋成熟的代码生成技术, 用注入的逻辑自动维护内存中关系模型下对象之间的引用关系也变为可能, 创建 和 删除 关系对象 时, 已经完全可以由数据库系统来自动修改它所连接起来的其他 持久对象 的 连接引用(Joint Reference), 从而维护整个内存中关系模型拓扑图的完整.

结论是: 对象技术其实不必借助 Mapping 就能实现和利用 关系模型, 现有的 ORM 其实只是在进行 OO语言编写的网络模型 到 关系模型 的映射.

面向对象的关系模型已经不是凭空的设想, 而是已经有可以实际应用的数据库产品, 就是我已经开发完成的 Ableverse The Object Base http://tob.ableverse.org, 它也不仅只是一个研究产品, 从开源的 WoW http://www.webofweb.net 产品表现, 可以看到它的商业质量.

不过 TOB 目前公开发行的还是版本 5, 开发时编译步骤还相对复杂.
计划元旦以后发布版本 6, 这个版本只需JDK6的javac, 没有任何多余步骤, 只需按平常开发Java程序的方法就可以编写基于TOB的持久应用, 通过Apache Ant, 也可以和流行Java IDE很好的集成.

基于TOB的持久应用, 全部源码只需Java类代码, 并且相对于 直接JDBC操作关系数据库, 或通过ORM方式, 数据库性能有几倍到几千倍的提升, 是关系数据库后台存储上的内存数据库性能.

评论

40 楼 litchi 2007-06-04  

歆渊 写道

litchi 写道

楼主的设想在一些商业应用上已经有了先例，Ariba公司的AML（Ariba MeteData language）与相对应的缓存模型定义完全完全将Java对象和关系数据契合在一起，将大量数据放在内存中，支持继承、复写、扩展、引用，完全将数据库层和Java对象层隔离出去。进行开发时，不需要考虑数据库层，也不需要考虑Java对象层，无需关心对象的创建、释放、提交等操作，对象只有在显式销毁时才被写入数据库，支持并发、效率也很高

有没有公开的网站包含更多信息的? google了一下没找到官方网站和活跃的讨论区, 你这个描述有点含糊:
没有

"进行开发时，不需要考虑数据库层，也不需要考虑Java对象层"
那写程序时关心什么?
写程序的重点在通过接口实现各种业务校验和逻辑,大部分对象是从系统框架的界面层获取的，当然也可以直接调用系统工厂方法进行对象的创建，修改，保存。（其实说白了就是体力活）


"无需关心对象的创建、释放、提交等操作"
连 new 对象都不用了? 确实想像不出这个程序是怎么编的了.
这个无需关心创建可能是我说的太忽悠,对象当然要创建的......我说的意思是它的整体框架处理了大部分你所要处理的业务对象的创建与保存工作，然后在它提供给你的接口中，它将足够的对象暴露给你，直接进行业务逻辑校验/处理，处理完成后不需要关心对象的保存，提交以及资源的释放。当然在考虑性能优化和其他问题的情况下，也可以显式的在必要的时候主动进行这些操作。


"对象只有在显式销毁时才被写入数据库"
那就是说数据库里只保存历史废品, 而且没销毁之前如果 power failure, 那数据就都蒸发了?
这个我最近看了一下,发现是有一个background的线程专门处理这个的,只要是在它的线程池中的线程对它的对象进行的操作,会定期的与数据库进行自动的同步，这个ms现在的框架都这么处理？

PS: 我觉得可能这个产品确实是很好的, 但是你这里的描述似乎不准确.

嗯,我的描述确实不准确。其实我对ORM这方面了解的很少，仅限于使用，所以可能说出来的话有点贻笑大方，对着这么优秀的框架只知道面对接口作一些体力活。

这个产品另一个很方便的地方是使用xml实现了数据定义的继承扩展复写，可以基于现有数据结构直接进行继承(override)，引用(import)，扩展(extend)，继承/扩展同一父类的数据结构可以在程序里面被统一处理无需考虑具体的类型。

这是Ariba的产品底层架构的一部分，只用在他们自己的产品里面，非开源非免费也没有讨论，我们也只能拿到接口，没有更进一步的资料。。。

39 楼 歆渊 2007-05-27  

litchi 写道

楼主的设想在一些商业应用上已经有了先例，Ariba公司的AML（Ariba MeteData language）与相对应的缓存模型定义完全完全将Java对象和关系数据契合在一起，将大量数据放在内存中，支持继承、复写、扩展、引用，完全将数据库层和Java对象层隔离出去。进行开发时，不需要考虑数据库层，也不需要考虑Java对象层，无需关心对象的创建、释放、提交等操作，对象只有在显式销毁时才被写入数据库，支持并发、效率也很高

有没有公开的网站包含更多信息的? google了一下没找到官方网站和活跃的讨论区, 你这个描述有点含糊:

"进行开发时，不需要考虑数据库层，也不需要考虑Java对象层"
那写程序时关心什么?


"无需关心对象的创建、释放、提交等操作"
连 new 对象都不用了? 确实想像不出这个程序是怎么编的了.


"对象只有在显式销毁时才被写入数据库"
那就是说数据库里只保存历史废品, 而且没销毁之前如果 power failure, 那数据就都蒸发了?


PS: 我觉得可能这个产品确实是很好的, 但是你这里的描述似乎不准确.

38 楼 litchi 2007-05-27  

楼主的设想在一些商业应用上已经有了先例，Ariba公司的AML（Ariba MeteData language）与相对应的缓存模型定义完全完全将Java对象和关系数据契合在一起，将大量数据放在内存中，支持继承、复写、扩展、引用，完全将数据库层和Java对象层隔离出去。进行开发时，不需要考虑数据库层，也不需要考虑Java对象层，无需关心对象的创建、释放、提交等操作，对象只有在显式销毁时才被写入数据库，支持并发、效率也很高

37 楼 歆渊 2007-05-25  

lihy70 写道

这里讨论实在令人耳目一新！
不过这里的概念实在有点难理解（可能今天心情不畅，看到这些东西差点心肌梗塞:-)）
首先对 歆渊 表示一下支持，为了更好的理解你的想法，我自私提一个你可能解释百编的问题，
（你举的那个婆媳，丈夫例子对我来说还是太复杂了点。）

我的例子是：
10，000个group，
1000，000个user
他们之间是多对多的关系，

这里首先会涉及到一个内存策略的问题, TOB是为大内存设计的, 假定自己运行在内存比较充裕的环境下.
但TOB并不是像传统内存数据库那样要把所有数据都加载进内存, 而是加载一个对象时要把所有和它物理连接的对象全部加载进内存.

拿这里的例子来说, 假如其中5,000个group只包含500,000个user, 而且因为这些user交错隶属于这5,000个中不同的group, 导致5,000个group和500,000个user都直接或间接关联, 形成一个封闭的对象图. 那么这时候如果应用需要其中某个group或者user对象的话, 这所有5,000个group和500,000个user就必须同时被加载进内存. 不过另外不相干的5,000个group和500,000个user就不需要加载了.

当然也有可能10,000个group和1000,000个user全部有关, 这种情况下就要看服务器内存是否同时容得下所有这些对象了, 如果内存没有那么大, 就不能用TOB的物理连接来设计持久类方案了, 否则铁定会 OutOfMemoryError.

这时可以通过逻辑连接, 既用一个数值型的持久字段来存储相关对象的 Object ID, 需要的时候以这个 ID值 向TOB要对象实例. TOB用Tree Table来处理这种请求, 对象已经加载情况下的性能损失可以基本忽略不计. 不过逻辑连接就享受不到TOB的ORK模型的好处了, 要自己实现相关对象的获取和一致性维护. 不过对不常用数据, 逻辑连接也不失为一个有效方法, 比如 WoW 保存信息节点的历史版本对象时就是用这种方式.


后面考虑这里问题的解决方案时我们就假定服务器内存足够大, 能够装下最大的 group-user 拓扑图. 这是能够最大限度发挥TOB优势的case.

lihy70 写道

你能否简单介绍一下用你的框架是怎么解决下面的问题：
1，怎么添加，更新，删除一个group或user？

添加:

 Group g = tob.birth(new Group("G 1"));
 User u = tob.birth(new User("Compl", "Ableverse"));

更新:
给 Group 和 User 类上修改持久字段的实例方法加上一个 @Writing 标注, 然后需要的时候直接调用就好了.

public class User extends TheObject
{
  ...
  @Writing
  public void setCompany(String c)
  {
     this.company = c;
  }
}

User u = tob.get(123);
u.setCompany("JavaEye");
tob.commitAllTransactions();

删除:
用从 TheObject 公共基类继承来的 void die(); 方法

User u = tob.get(123);
u.die();
tob.commitAllTransactions();

lihy70 写道

2，怎么添加，更新，删除group和user之间的关系？

定义一个关系类:

public class Membership extends TheRelation
{
  protected Tie<Group> group;
  protected Tie<User> member;

  public Membership(Group g, User u)
  {
    this.group = new Tie<Group>(g);
    this.member = new Tie<User>(u);
  }

  public Group getGroup()
  {
    return group == null ? null : group.o;
  }

  @Retying ("group")
  public void changeGroup(Group g)
  {
    this.group = new Tie<Group>(g);
  }

  // similar for memeber
  ...
}

然后添加:

Group g = ...;
User u = ...;
Membership m = tob.birth(new Membership(g, u));
tob.commitAllTransactions();

更新:

Group g = ...;
Membership m = ...;
m.changeGroup(g);
tob.commitAllTransactions();

删除:

Membership m = ...;
m.die();
tob.commitAllTransactions();

lihy70 写道

3，怎么根据特定的条件查询group，user，以及一个group下面的user或一个user属于的group？

特定的条件利用SQL, TOB根据持久类的持久字段生成用于拼装SQL的条件类. 本质还是SQL, 就不举例了.
不过表里的总数据量超大, 单个关联对象的数据量较小, 或者SQL条件异常复杂时, 可能自己遍历KinSet集合用Java代码进行判断筛选的方案效率更高. 比如 WoW 的操作权限校验过程.

user的groups和group的users通过定义KinSet来实现:

public class User extends TheObject
{
  @IAm("member") // optional since no ambiguity to clearify
  @TheyAre("group") // optional since no ambiguity to clearify
  private KinSet<Membership, Group> groups;

  public List<Group> listGroups()
  {
    List<Group> gs = new ArrayList<Group>(groups.size());
    for(Kin<Membership, Group> gKin : groups)
      gs.add(gKin.getO());
    return gs;
  }
}

// users kin for class Group is similar

lihy70 写道

4，怎么控制并发操作？

TOB在底层控制事务, 目前是绑定到当前线程. 应用只需要在完成单元操作后调用 tob.commitAllTransactions(); 就可以了. TOB可以配置为通过 悲观锁 或者 乐观锁 进行冲突防止和仲裁. 应用需要做的就只是给自己的持久类上进行排他读取的方法加上 @Reading 标注, 修改持久字段的方法加上 @Writing 标注, 持久关系类上修改Tie字段的方法加上 @Retying 标注.

lihy70 写道

5，怎么load或save内存中user和group的实例（或数据）？

不需要显式的load或save.
通过OID或者查询获得持久对象时, TOB把它加载好了才返回给应用.
如果调用了某个对象标注为@Writing的方法, 则 tob.commitAllTransactions(); 的时候就会保存它.


另外 tob.startNewTransaction(); tob.commitCurrentTransaction(); tob.commitAllTransactions(); 以及相应的 rollback 方法, 一般在应用框架级别上做就可以了, 应用功能代码鲜少需要直接跟这些打交道.

还有就是如果 rollback 了, 对象的持久字段会自动恢复到事务之前的的取值, 应用如果保存了对象引用还是继续有效, 指向正确的对象, 不需要重新查询或者什么特殊操作.

36 楼 lihy70 2007-05-22  

这里讨论实在令人耳目一新！
不过这里的概念实在有点难理解（可能今天心情不畅，看到这些东西差点心肌梗塞:-)）
首先对 歆渊 表示一下支持，为了更好的理解你的想法，我自私提一个你可能解释百编的问题，
（你举的那个婆媳，丈夫例子对我来说还是太复杂了点。）

我的例子是：
10，000个group，
1000，000个user
他们之间是多对多的关系，

你能否简单介绍一下用你的框架是怎么解决下面的问题：
1，怎么添加，更新，删除一个group或user？
2，怎么添加，更新，删除group和user之间的关系？
3，怎么根据特定的条件查询group，user，以及一个group下面的user或一个user属于的group？
4，怎么控制并发操作？
5，怎么load或save内存中user和group的实例（或数据）？

最好仅仅介绍你的方案是怎么做的，先不要介绍你这样做的理论根据，也不要涉及关系数据，ORM，以及面向对象的数据库是怎么做到这些的。

非常期待你的回答！
谢谢！

35 楼 歆渊 2007-01-11  

eyejava 写道

一个男人，一个女人结婚，就这么两个节点怎么会是网络模型呢？网络模型用数据结构来表达应该是图吧，没有很多节点用的着搬出“图”这种东西吗。两个点的连线就只有一条而已，什么结构都能称上，关系数据库是一种表达方式，把实体和关系存储成表的样子，对象也是一种表达方式。对于简单的两个节点都很容易表达。
我觉得网络的样子应该是：1级节点 有N个2级节点，2级节点有N个3级节点，依此类推，层次可能是比较深的，无法预知的；如果节点的父节点只有一个，那就是树形结构，是比较简单的网络，用对象也比较容易表达，如果父节点有多个，就比较麻烦了，关系数据库和对象都挺难表达出来，不知道tob怎么处理这种问题。

"如果节点的父节点只有一个，那就是树形结构，是比较简单的网络"
-- 这个是 层次模型(Hierarchical Model), 在网络模型前被提出来的.
"如果父节点有多个，就比较麻烦了"
-- 这个就是 网络模型(Network Model) 被提出的原因, 就是为了在 层次模型 的基础上解决多父的问题.

这些数据模型问题基本都是在上世纪六,七十年代集中讨论的, 要查点古董资料才能搞清楚的.

如果对很理论性的东西不是很感兴趣, 关注实用实践更多一些, 可以时常留意看看

http://tob.ableverse.org/pattern.html

这个地方, 陆续会有面向不同应用的新持久模型样板代码出来.

如果目前有兴趣又有时间, 可以下载

http://wow.dev.java.net

的代码研究看看基于 TOB 对网状数据结构的建模处理.

34 楼 eyejava 2007-01-11  

一个男人，一个女人结婚，就这么两个节点怎么会是网络模型呢？网络模型用数据结构来表达应该是图吧，没有很多节点用的着搬出“图”这种东西吗。两个点的连线就只有一条而已，什么结构都能称上，关系数据库是一种表达方式，把实体和关系存储成表的样子，对象也是一种表达方式。对于简单的两个节点都很容易表达。
我觉得网络的样子应该是：1级节点 有N个2级节点，2级节点有N个3级节点，依此类推，层次可能是比较深的，无法预知的；如果节点的父节点只有一个，那就是树形结构，是比较简单的网络，用对象也比较容易表达，如果父节点有多个，就比较麻烦了，关系数据库和对象都挺难表达出来，不知道tob怎么处理这种问题。

33 楼 歆渊 2007-01-11  

嗯, 说到这里, 目前 基于关系数据库 的 对象持久问题, 主流方案一直是 应用程序(通过DAO) 或者 框架/容器(通过ORM) 来关心的.
而TOB呢, 是使得这个持久问题改由 数据库管理系统 来关心了, 应用程序 指定 What, 数据库 实现 How. 看来也可以作为一个宣传卖点了

32 楼 firebody 2007-01-10  

complystill 写道

msg db 'Hello$'
 mov dx, offset msg
 mov ah, 9
 int 21h
 mov ah, 4Ch
 int 21h

这个非常明确: 调用 DOS 系统功能显示一个字符串.
汇编一下可以直接测试不需要 CRT, 用 debug 写个 .com 连汇编都可以省了, 甚至直接在 debug 里逐句执行都可以.

#include <stdio.h>
int main(int argc, char** argv)
{
 puts("Hello");
 return 0;
}

这个要包含头文件, 写 main 函数, 还要先编译成 .obj, 再链接成 .exe, 最后在 CRT 的环境下才能执行测试. 在DOS环境下完成功能的最终还是差不多的几条指令.


综合来看两种途径同样去显示一个字符串, 工作量差别也不大.
...
感觉很多差别是系统复杂度导致的, 量变引起质变.

东西少的时候, 可以看到 "HOW", 觉得明白, 心里也踏实.
太多了以后, 可能对相同层面的问题, 就会更愿意只关心 "WHAT", 把实现 "分包" 给专门系统去处理.

问题的关键是 有些问题 理应 由 开发者关心，有些东西理应由框架或者语言来关心，正如你说的synchronized ,也正如你上面提到的语言级别的东西。

31 楼 歆渊 2007-01-10  

msg db 'Hello$'
 mov dx, offset msg
 mov ah, 9
 int 21h
 mov ah, 4Ch
 int 21h

这个非常明确: 调用 DOS 系统功能显示一个字符串.
汇编一下可以直接测试不需要 CRT, 用 debug 写个 .com 连汇编都可以省了, 甚至直接在 debug 里逐句执行都可以.

#include <stdio.h>
int main(int argc, char** argv)
{
 puts("Hello");
 return 0;
}

这个要包含头文件, 写 main 函数, 还要先编译成 .obj, 再链接成 .exe, 最后在 CRT 的环境下才能执行测试. 在DOS环境下完成功能的最终还是差不多的几条指令.


综合来看两种途径同样去显示一个字符串, 工作量差别也不大.
...
感觉很多差别是系统复杂度导致的, 量变引起质变.

东西少的时候, 可以看到 "HOW", 觉得明白, 心里也踏实.
太多了以后, 可能对相同层面的问题, 就会更愿意只关心 "WHAT", 把实现 "分包" 给专门系统去处理.

30 楼 firebody 2007-01-10  

complystill 写道

firebody 写道

首先，我觉得楼主说得“关系模型”和 “网络模型”似乎不存在明显的界限，我更加愿意把这两个模型当作设计设计领域模型的结果。 或许这两个名词根本不存在。  为什么这样说呢？ 因为我看到这段话：

引用

网络模型 中没有对应于 婚姻关系 的信息载体, 是通过两个对等的引用来表达: 一个 男人 的 妻子 引用 指向另一个 女人; 而这个 女人 的 丈夫 引用必须也指向这个 男人. 所以结婚的操作是同时设置这两个引用, 离婚的操作是同时清除这两个引用. 引用对的 原子对等性 要由应用程序来保证, 这在并发环境中每个地方都需要仔细的使用资源互斥.

关系模型 中, 婚姻关系 是一个专门的对象, 结婚操作就是创建这个对象, 离婚操作就是删除这个对象. 如果夫妻双方需要保存到对方的相互引用, 这个引用也是由 数据库管理系统 去维护的, 并发控制也完全由数据库系统管理.

从上面这段话来看，婚姻关系 在建模设计里面似乎是一个设计的结果，这个和模型名次没有更多的关系。 通过引用 和 通过一个专有的类 来表示建立婚姻。 这个设计是领域模型的不同设计的结果，这个结果和具体的需求又关系，和 “网络/关系模型”没有关系。


至于说 关系之间的自动维护，这个便利如果可以轻松获得那么还是很有好处的，不过这个好处带来的优势似乎并不是很大，在项目开发里面，特别是ERP开发里面，分析 这种 “关系之间的关系（比如举个例子来说, 比如婆媳关系, 为什么你的母亲是你妻子的婆婆, 而你妻子是你母亲的儿媳呢? 是因为你和你妻子存在婚姻关系. 假设你和你妻子离婚的话, 那婆媳关系则自动解除）”的工作是占据领域模型分析工作很大比例的一部分，而得到这个分析结果 再依次关系建立 关系维护逻辑的工作量则不是很大，需要的仅仅是明确的方法，至于你提到的关系的自动维护，应该也是基于这个 领域关系的分析基础之上的。  所以，在OO开发里面，这种关系的自动维护 和 手工维护 的对比 似乎不是我们所主要关注的部分。

如果从最终可以解决的问题来说确实是殊途同归:
C++和Java都是面向对象的编程语言, 只要灵活熟练的掌握, 完全可以写出同样的程序功能.
网络模型 和 关系模型 也都是数据模型, 能够灵活熟练运用, 完全可以解决同样的问题.

有些细小的差别, 比如 C++ 里需要自己建 Mutex 或者 临界区, 手工 获取 和 释放; 而Java里一个 synchronized 块就搞定.
但是 线程安全 总是一个统一的 设计结果, 是由 需求 决定的, 和 开发语言 没有关系.

只讨论 OO 开发的话, 到底用 C++ 还是 Java 去写代码也不是主要关注的部分.

说到这点 ，比较“一个明确意义的方法“ 和 “需要配置关系之间的关系的声明“，不知道这两者之间工作量差别是否很大？ 当然还有一个额外的需求，希望“关系之间的关系的声明“和需求的分析结果一样直白易懂，至少清晰的代码还是可以达到这个要求的。  另外，也还希望加上可测试性的要求。希望不自动化到我得到数据库里面去验证结果就好了。

29 楼 歆渊 2007-01-10  

firebody 写道

首先，我觉得楼主说得“关系模型”和 “网络模型”似乎不存在明显的界限，我更加愿意把这两个模型当作设计设计领域模型的结果。 或许这两个名词根本不存在。  为什么这样说呢？ 因为我看到这段话：

引用

网络模型 中没有对应于 婚姻关系 的信息载体, 是通过两个对等的引用来表达: 一个 男人 的 妻子 引用 指向另一个 女人; 而这个 女人 的 丈夫 引用必须也指向这个 男人. 所以结婚的操作是同时设置这两个引用, 离婚的操作是同时清除这两个引用. 引用对的 原子对等性 要由应用程序来保证, 这在并发环境中每个地方都需要仔细的使用资源互斥.

关系模型 中, 婚姻关系 是一个专门的对象, 结婚操作就是创建这个对象, 离婚操作就是删除这个对象. 如果夫妻双方需要保存到对方的相互引用, 这个引用也是由 数据库管理系统 去维护的, 并发控制也完全由数据库系统管理.

从上面这段话来看，婚姻关系 在建模设计里面似乎是一个设计的结果，这个和模型名次没有更多的关系。 通过引用 和 通过一个专有的类 来表示建立婚姻。 这个设计是领域模型的不同设计的结果，这个结果和具体的需求又关系，和 “网络/关系模型”没有关系。


至于说 关系之间的自动维护，这个便利如果可以轻松获得那么还是很有好处的，不过这个好处带来的优势似乎并不是很大，在项目开发里面，特别是ERP开发里面，分析 这种 “关系之间的关系（比如举个例子来说, 比如婆媳关系, 为什么你的母亲是你妻子的婆婆, 而你妻子是你母亲的儿媳呢? 是因为你和你妻子存在婚姻关系. 假设你和你妻子离婚的话, 那婆媳关系则自动解除）”的工作是占据领域模型分析工作很大比例的一部分，而得到这个分析结果 再依次关系建立 关系维护逻辑的工作量则不是很大，需要的仅仅是明确的方法，至于你提到的关系的自动维护，应该也是基于这个 领域关系的分析基础之上的。  所以，在OO开发里面，这种关系的自动维护 和 手工维护 的对比 似乎不是我们所主要关注的部分。

如果从最终可以解决的问题来说确实是殊途同归:
C++和Java都是面向对象的编程语言, 只要灵活熟练的掌握, 完全可以写出同样的程序功能.
网络模型 和 关系模型 也都是数据模型, 能够灵活熟练运用, 完全可以解决同样的问题.

有些细小的差别, 比如 C++ 里需要自己建 Mutex 或者 临界区, 手工 获取 和 释放; 而Java里一个 synchronized 块就搞定.
但是 线程安全 总是一个统一的 设计结果, 是由 需求 决定的, 和 开发语言 没有关系.

只讨论 OO 开发的话, 到底用 C++ 还是 Java 去写代码也不是主要关注的部分.

28 楼 firebody 2007-01-09  

complystill 写道

_克斯 写道

1.我理解你的意思是这样的：
比如数据库中有三张表，Reader，Book，Borrow。
对象模型中有三个类与之对应，Reader，Book，Borrow。
也就是说不必对象建模，直接按照在数据库设计中建好关系表，自动生成类文件就可以了。

如果说是TOB里的情况的话, 刚好是反过来:
写好了 Reader，Book，Borrow 三个类, 运行程序的时候创建TOB实例, 它会自动创建这三张数据库表, 如果已经存在则检查是否有缺失的列或者索引, 有的话自动补齐. 然后控制再返回给应用程序继续运行.

_克斯 写道

2.

complystill 写道

嗯, 网络模型是计算机世界的天然模型, 用来解决计算问题最恰当.
关系模型是自然世界的天然模型, 用来建模解决现实世界的问题最恰当.

姑且不论第一句话是否正确，第二句，怎么能说“关系模型是自然世界的天然模型”呢，网络模型才是吧。

举个例子来说, 比如婆媳关系, 为什么你的母亲是你妻子的婆婆, 而你妻子是你母亲的儿媳呢? 是因为你和你妻子存在婚姻关系. 假设你和你妻子离婚的话, 那婆媳关系则自动解除.

但是在网络模型里, 没法区分婆媳关系与夫妻关系的差别, 都是直接到对方的引用, 妻子或者儿媳, 丈夫或者婆婆. 而要维护婆媳关系对婚姻关系的依赖性, 就必须应用程序自己实现某种触发机制, 当婚姻关系被删除时, 自动去清除 儿媳 和 婆婆 引用.

但如果用关系模型就自然多了, 删除掉婚姻关系, 则婆媳关系自然解除.

当然这在基于SQL的关系数据库中最容易实现, 因为它表达的 婆媳关系 本来就只存在于逻辑上, 要通过查询时的 JOIN 去引用.

到了面向对象的关系模型里, 应用还是需要到 婆婆 和 儿媳 的直接引用. 这个时候的差别就在于, 如果走 网络模型 的路, 则这些引用要由应用自己触发维护, 而如果走 对象关系模型 的路, 应用只要按照模型的框架声明这些引用, 关系对象数据库管理系统 就可以隐含的自动完成这些维护.


婆媳 和 夫妻 关系是现实逻辑上比较容易理解的例子, 落到计算机建模处理的情况中, 其实 妻子 和 丈夫 引用 就是 男人 和 女人 两个类上常规的两个成员变量.

网络模型 中没有对应于 婚姻关系 的信息载体, 是通过两个对等的引用来表达: 一个 男人 的 妻子 引用 指向另一个 女人; 而这个 女人 的 丈夫 引用必须也指向这个 男人. 所以结婚的操作是同时设置这两个引用, 离婚的操作是同时清除这两个引用. 引用对的 原子对等性 要由应用程序来保证, 这在并发环境中每个地方都需要仔细的使用资源互斥.

关系模型 中, 婚姻关系 是一个专门的对象, 结婚操作就是创建这个对象, 离婚操作就是删除这个对象. 如果夫妻双方需要保存到对方的相互引用, 这个引用也是由 数据库管理系统 去维护的, 并发控制也完全由数据库系统管理.

所以建模处理这些现实问题, 还是 关系模型 来的更自然,贴切.

很久没来参加这个讨论，就是怕空对空。 不是说楼主作的框架不好，是觉得讨论在这样概念满天飞的情况下，很容易因为理解的不一致出现空对空。

现在终于有了楼主举出的这个例子，我想针对楼主提到的这个例子来说说我的看法。

首先，我觉得楼主说得“关系模型”和 “网络模型”似乎不存在明显的界限，我更加愿意把这两个模型当作设计设计领域模型的结果。 或许这两个名词根本不存在。  为什么这样说呢？ 因为我看到这段话：

引用

网络模型 中没有对应于 婚姻关系 的信息载体, 是通过两个对等的引用来表达: 一个 男人 的 妻子 引用 指向另一个 女人; 而这个 女人 的 丈夫 引用必须也指向这个 男人. 所以结婚的操作是同时设置这两个引用, 离婚的操作是同时清除这两个引用. 引用对的 原子对等性 要由应用程序来保证, 这在并发环境中每个地方都需要仔细的使用资源互斥.

关系模型 中, 婚姻关系 是一个专门的对象, 结婚操作就是创建这个对象, 离婚操作就是删除这个对象. 如果夫妻双方需要保存到对方的相互引用, 这个引用也是由 数据库管理系统 去维护的, 并发控制也完全由数据库系统管理.

从上面这段话来看，婚姻关系 在建模设计里面似乎是一个设计的结果，这个和模型名次没有更多的关系。 通过引用 和 通过一个专有的类 来表示建立婚姻。 这个设计是领域模型的不同设计的结果，这个结果和具体的需求又关系，和 “网络/关系模型”没有关系。


至于说 关系之间的自动维护，这个便利如果可以轻松获得那么还是很有好处的，不过这个好处带来的优势似乎并不是很大，在项目开发里面，特别是ERP开发里面，分析 这种 “关系之间的关系（比如举个例子来说, 比如婆媳关系, 为什么你的母亲是你妻子的婆婆, 而你妻子是你母亲的儿媳呢? 是因为你和你妻子存在婚姻关系. 假设你和你妻子离婚的话, 那婆媳关系则自动解除）”的工作是占据领域模型分析工作很大比例的一部分，而得到这个分析结果 再依次关系建立 关系维护逻辑的工作量则不是很大，需要的仅仅是明确的方法，至于你提到的关系的自动维护，应该也是基于这个 领域关系的分析基础之上的。  所以，在OO开发里面，这种关系的自动维护 和 手工维护 的对比 似乎不是我们所主要关注的部分。

27 楼 歆渊 2007-01-09  

_克斯 写道

谢谢楼主的回答。
你举的婆媳的例子并不能论证 关系模型是自然世界的天然模型，婆媳关系或者结婚离婚并不是一张纸，虽然这张纸的信息你可以用关系模型来记录。关系，是通过行为来体现的，关系模型或者用关系数据库只是存储表征这种系统行为的信息的一种方式。
比如一个人Person类，有age,height,sex等自然属性，他白天可以是一个警察，下班回家是丈夫，周末看望老人是儿子，这种社会关系（相对于自然属性来讲）是通过行为来体现的，因此该Person类可以implements Policeman,implements Husband,implements Son来表现这种关系，Policeman，Husband，Son这三个接口可以定义相应方法来定义这种社会关系。
在关系模型中记录的仅仅是自然世界的简化，贫乏和静态的信息，决然不能说 关系模型是自然世界的天然模型。

关于天然模型的判断倒确实是见仁见智, 我原来的说法是过于绝对了, 可能加上在 自然世界的企业管理 范畴, 通过计算机自动化工具来建模解决时, 说 "关系模型更自然贴切" 更恰当. 我原来主要是搞PDM/PLM的, 偶尔接触一些ERP. 在这些系统里数据建模只关心企业需要管理的部分, 其中错综复杂的, 相依存的关系很多, 也基本都是抽象以后的建模, 所以关系模型会显得更优越一些.

如果是做一个自然世界的真实模拟, 比如FPS游戏中的 物理引擎, 负责计算虚拟物体的重力影响, 物体之间的作用力/反作用力, 速度/加速度 以及破坏分解等等, 类似应用可能还是 网络模型 更合适. 不过这方面的应用我个人还是觉得更偏向于 运算问题, 因为更多的是 计算模型.

你举的人在不同情景下的不同角色例子, 我觉得应该可以说是一个 数据库应用, 它本身和 网络模型 或 关系模型 其实不是一个层次的事物, 应该说它可以基于 网络模型 去实现, 也可以基于 关系模型 去实现, 如果真正落到用计算机工具去建模解决的工作的话, 结合具体情况和要求也不一定哪个更好用的.

_克斯 写道

我还想问个问题，并发和事务你是放在哪里处理的？是放在关系对象模型中，还是放在你的内存数据库中？是如何处理的？

TOB对并发和事物控制是在内存对象级别自己实现的, 它根据应用的持久类中声明的相关语义去进行适当的处理.

我理解你这里说的 "关系对象模型" 是指 应用程序通过持久Java类代码定义出来的 持久对象模型, 如果这样理解没有问题, 那么这个问题可以这样回答:

在应用的持久类中对于读取本对象 持久属性 的方法加注 @Reading 标注(这个只对完整性敏感数据,比如存款余额等,有必要性. 其他情况可以省略这个标注以提高一定程度的运行时性能), 对于更改本对象 持久属性 的方法加注 @Writing 标注(这个是必须的), 另外对于更改对象之间引用关系的方法加注 @Retying 标注.

这样应用程序要做的就是声明这些事务控制要求, 然后编译时 TOB 会自动生成支持类, 实现相应的控制逻辑, 运行时那些支持类则发挥作用, 实现并发环境下的数据ACID特性.
另外对于事物的 提交/撤销 操作, 一般在应用框架层次实现, 类似 Hibernate 的 OpenSessionInView, 不过TOB的事务要轻量得多, 不依赖于 JDBC 连接, 所以没有 OpenSessionInView 的潜在性能问题.

更多一些的实现细节描述可以参考一下我这篇回帖: http://www.iteye.com/post/179096

26 楼 歆渊 2007-01-09  

andyandyandy 写道

很赞赏楼主的工作！

谢谢!

andyandyandy 写道

1，既然是把类直接映射到内存中生成表，那在操作表的时候，就跟操作类一样了吧，这样就省去了orm映射的过程，通过一种特定的查询语句直接将检索到的数据映射到类中了，同样，增删改也是如此。

从面向对象的视角看, 就没有 表 的概念了, 操作的就是内存中的持久对象拓扑图.
查询可以是通过遍历函数搜索这个对象拓扑图, TOB也支持通过 SQL 查询, 这种情况下其实是通过底层关系数据库的SQL检索能力, 找出对象的ID, 然后根据这些 ID 再返回给应用内存中的持久对象.

andyandyandy 写道

2，在内存中存储的话，tob在什么时候加载的呢？关掉tob服务的时候，数据有放到什么地方呢？怎么放的呢？

为了满足数据库的 ACID 特性, 数据是不能只存在于内存里的, TOB 有一个 SwapEngine 的抽象层, 目前只有通过 JDBC 操作传统关系数据库的实现. 这个有点类似 物理内存 和 交换分区/交换文件 的关系, 读取数据时有点像 冬眠 的电脑再加电的时候恢复到 冬眠 以前的运行状态. (XP这点比较厉害, 很早以前我用笔记本玩3D游戏, 后来没注意电池没电了, 自动冬眠, 然后回到家插上电游戏还可以接着玩, 呵呵)

相关的一点设计思想可以看看我这篇回帖: http://www.iteye.com/post/178815

内存加载相关一些内容可以参考我这篇回帖: http://www.iteye.com/post/179096

25 楼 _克斯 2007-01-09  

谢谢楼主的回答。
你举的婆媳的例子并不能论证 关系模型是自然世界的天然模型，婆媳关系或者结婚离婚并不是一张纸，虽然这张纸的信息你可以用关系模型来记录。关系，是通过行为来体现的，关系模型或者用关系数据库只是存储表征这种系统行为的信息的一种方式。
比如一个人Person类，有age,height,sex等自然属性，他白天可以是一个警察，下班回家是丈夫，周末看望老人是儿子，这种社会关系（相对于自然属性来讲）是通过行为来体现的，因此该Person类可以implements Policeman,implements Husband,implements Son来表现这种关系，Policeman，Husband，Son这三个接口可以定义相应方法来定义这种社会关系。
在关系模型中记录的仅仅是自然世界的简化，贫乏和静态的信息，决然不能说 关系模型是自然世界的天然模型。


我还想问个问题，并发和事务你是放在哪里处理的？是放在关系对象模型中，还是放在你的内存数据库中？是如何处理的？

24 楼 andyandyandy 2007-01-09  

很赞赏楼主的工作！
1，既然是把类直接映射到内存中生成表，那在操作表的时候，就跟操作类一样了吧，这样就省去了orm映射的过程，通过一种特定的查询语句直接将检索到的数据映射到类中了，同样，增删改也是如此。
2，在内存中存储的话，tob在什么时候加载的呢？关掉tob服务的时候，数据有放到什么地方呢？怎么放的呢？

23 楼 歆渊 2007-01-09  

_克斯 写道

1.我理解你的意思是这样的：
比如数据库中有三张表，Reader，Book，Borrow。
对象模型中有三个类与之对应，Reader，Book，Borrow。
也就是说不必对象建模，直接按照在数据库设计中建好关系表，自动生成类文件就可以了。

如果说是TOB里的情况的话, 刚好是反过来:
写好了 Reader，Book，Borrow 三个类, 运行程序的时候创建TOB实例, 它会自动创建这三张数据库表, 如果已经存在则检查是否有缺失的列或者索引, 有的话自动补齐. 然后控制再返回给应用程序继续运行.

_克斯 写道

2.

complystill 写道

嗯, 网络模型是计算机世界的天然模型, 用来解决计算问题最恰当.
关系模型是自然世界的天然模型, 用来建模解决现实世界的问题最恰当.

姑且不论第一句话是否正确，第二句，怎么能说“关系模型是自然世界的天然模型”呢，网络模型才是吧。

举个例子来说, 比如婆媳关系, 为什么你的母亲是你妻子的婆婆, 而你妻子是你母亲的儿媳呢? 是因为你和你妻子存在婚姻关系. 假设你和你妻子离婚的话, 那婆媳关系则自动解除.

但是在网络模型里, 没法区分婆媳关系与夫妻关系的差别, 都是直接到对方的引用, 妻子或者儿媳, 丈夫或者婆婆. 而要维护婆媳关系对婚姻关系的依赖性, 就必须应用程序自己实现某种触发机制, 当婚姻关系被删除时, 自动去清除 儿媳 和 婆婆 引用.

但如果用关系模型就自然多了, 删除掉婚姻关系, 则婆媳关系自然解除.

当然这在基于SQL的关系数据库中最容易实现, 因为它表达的 婆媳关系 本来就只存在于逻辑上, 要通过查询时的 JOIN 去引用.

到了面向对象的关系模型里, 应用还是需要到 婆婆 和 儿媳 的直接引用. 这个时候的差别就在于, 如果走 网络模型 的路, 则这些引用要由应用自己触发维护, 而如果走 对象关系模型 的路, 应用只要按照模型的框架声明这些引用, 关系对象数据库管理系统 就可以隐含的自动完成这些维护.


婆媳 和 夫妻 关系是现实逻辑上比较容易理解的例子, 落到计算机建模处理的情况中, 其实 妻子 和 丈夫 引用 就是 男人 和 女人 两个类上常规的两个成员变量.

网络模型 中没有对应于 婚姻关系 的信息载体, 是通过两个对等的引用来表达: 一个 男人 的 妻子 引用 指向另一个 女人; 而这个 女人 的 丈夫 引用必须也指向这个 男人. 所以结婚的操作是同时设置这两个引用, 离婚的操作是同时清除这两个引用. 引用对的 原子对等性 要由应用程序来保证, 这在并发环境中每个地方都需要仔细的使用资源互斥.

关系模型 中, 婚姻关系 是一个专门的对象, 结婚操作就是创建这个对象, 离婚操作就是删除这个对象. 如果夫妻双方需要保存到对方的相互引用, 这个引用也是由 数据库管理系统 去维护的, 并发控制也完全由数据库系统管理.

所以建模处理这些现实问题, 还是 关系模型 来的更自然,贴切.

22 楼 _克斯 2007-01-08  

1.我理解你的意思是这样的：
比如数据库中有三张表，Reader，Book，Borrow。
对象模型中有三个类与之对应，Reader，Book，Borrow。
也就是说不必对象建模，直接按照在数据库设计中建好关系表，自动生成类文件就可以了。

2.

complystill 写道

嗯, 网络模型是计算机世界的天然模型, 用来解决计算问题最恰当.
关系模型是自然世界的天然模型, 用来建模解决现实世界的问题最恰当.

姑且不论第一句话是否正确，第二句，怎么能说“关系模型是自然世界的天然模型”呢，网络模型才是吧。

21 楼 歆渊 2007-01-05  

mowendi 写道

你的工作成果非常漂亮！
在应用上，是否考虑过这两个方面：
（1）在电信、银行核心资源的管理上
（2）IBM的通用存储数据跟你的工作成果是否有类比性

谢谢!

这个有些遗憾, 因为产品刚刚起步, 还没有深入到具体行业, 到目前为止的假象应用领域主要还是 Web 和 HPC.

所以 （1） 的问题目前还没有精力照顾到.

（2）IBM的通用存储数据 这个我还真没有什么了解, 我目前的产品是一个更高效利用大内存的对象数据库, 如果是结构化的对象数据, 而且内存比较大, 会发挥出其优势. 对于其他类型的数据存储, 还没有针对性的考虑过可行性.