关系数据库性能问题（续）--引用

五 Object Relational Database 和O/R Mapping

主流关系数据库厂商都在产品中加入Object特性，支持用户自定义类型，嵌套表等，称为Object Relational Database。
看到的文章和文档里面说，Object Relational Database只是在Relational Database之上增加了一些更多的复杂类型，而基础的Infrastructure没有太大变化。
Relational Database由于 二维表结构的限制，都是Mainframe方式，无法实现 Database Cluster，支持的并发连接访问量有限，如果要提高容量和性能，只能购买更好的主机硬件。Transaction中Lock的粒度也只能是Table或者Row，不是过大就是过小。不知道是不是这样？
Object Database能够实现Database Cluster，分布式对象缓存也支持得不错。数据量增大，并发连接访问量增大的时候，只要在Database Cluster中增加多台一般的计算机。Transaction中Lock的粒度能够控制的很好，只锁住恰好需要处理的Object和Associated Objects。
Objectivity的文档里面这样说，用户可以事先把需要处理的所有关联的Objects放到一个Container里面，然后锁住这个Container。

对象数据库的Java API一般都号称 遵守ODMG3.0 and/or JDO1.0。开源的Object Database实现和 ODMG 实现，大致看了一眼 Ozone 的相关源码，觉得不错。
ODMG和JDO的目的，是提供一个 对象数据库 和 (关系数据库 + O/R) 无差别的API层。关系数据库的O/R Mapping遵守ODMG和JDO，对象数据库的API也遵守ODMG和JDO。这样，不用管下面用的是什么是数据库，用户都通过ODMG和JDO API，当作 对象数据库来使用。

关系数据库都支持标准SQL，但都提供了自己的native enhanced feature。对象数据库更是如此，API中除了包括ODMG或JDO，额外还提供了很多Native Feature的声明调用。我感觉，使用对象数据库，也许比使用 关系数据库更难移植。不知道是不是这样？
O/R Mapping天生就是用来把 关系数据库 包装成 对象数据库的使用方法的，自然就掩盖了各关系数据库之间的不同。

这里有个wiki page，估计是Hibernate Group的人总结的。列出了几乎所有的O/R Mapping tools的各方面特性的比较。有兴趣的朋友，可以在这个wiki page里面加入自己的作品。

引用

原文
http://c2.com/cgi/wiki?ObjectRelationalToolComparison

This page has been created to compare Java ObjectRelationalMapping layers. This should help potential users to make an educated choice of O/R technology and to better understand the existing products.

 

六 相关资料

 

引用

Service-Architecture在线文章列表
http://www.service-architecture.com/articles/index.html

其中，
These articles provide a basic background on concepts and standards for database management systems (DBMS). Many of these concepts apply to all forms of database management systems: relational (RDBMS), object (ODBMS), XML (XDBMS), and others as well as object-relational mapping and XML-mapping products

 

 

引用

http://www.unixspace.com/context/databases.html

这个很牛。列出来一堆的Database Model.
Hierarchical Model,
Network Model,
Relational Model,
Object/Relational Model,
Object-Oriented Model,
Associative Model,
Entity-Attribute-Value (EAV) data model,

最后提出了自己的作品的Model.
Context Model.
包括了上述所有的Model。

 

 

复杂的sql，性能肯定好不到哪里去。
高性能的系统，要尽可能使用简单的sql。
在一次会话中select很多次，很容易把数据库搞死。递归和循环代码中的查询，一般是要避免的。
基本表映射成一个行的集合，这个集合是Singleton的,并且可以按ID找出行。那么基本表可以不用每次都查询。在基本表集合第一次被请求时查询一次数据库，然后就保存在内存中。当基本表改变的时候，刷新基本表行的集合。
业务表映射成业务对象。业务对象中引用基本表的对象的时候，到基本表集合中去找，而不是去查数据库。这样应该可以避免join或者循环的select了。join也是比较消耗服务器资源的，特别是join的表比较多和层次比较深的情况。
大致是这样的

代码

class BaseObj{
int getId();
...
}
//这个Collection最好自己实现，提高性能，避免在查找中遍历集合
class BaseObjectList{
BaseObj findById(int id);
static getInstance();
}
class BusinessObject{
...
int baseObjId;
BaseObj getBaseObj(){
[b]return BaseObjectList.getInstance().findById(baseObjId);[/b]
}
}

<script>render_code();</script>
对于大表Join小表的情况，提高性能解决方法就是把小表始终放到内存里。