对象存储该怎么走？

五年前，当我提到已经面向对象了，不用再设计数据库时，许多人嗤之以鼻。今天，大量的ORM涌现，甚至于JDO2.0与EJB3.0轮番出战。面对如此热闹的场面，我不禁再次提出置疑，这么做对吗？

让我们简单回顾一番历史，重新考察一次数据库到底是做什么用的。也许您认为，数据库就是存储数据的仓库，仅此而已，这也是目前所有ORM技术的根本假设，但这也正是问题所在。传统的关系数据库不仅仅存储数据，而且存储数据处理的过程（包括存储过程及触发器）。也就是说，如果传统关系数据库仅存储数据，那么就不应当称作DBMS，就失去了数据管理的功能。数据库不仅存储数据，还管理数据。而目前的ORM技术把数据库的管理功能丢失了。这会带来问题吗？会，一定会，其中最主要的问题就是性能问题。假设有如下查询：select user from User where user.isBusy(); 在很多ORM产品中都支持这样的基于对象的简便查询。问题是，该查询包括一个对象的方法条件，无论您怎么做，您都只能把所有user对象（不管是否满足条件）全部由数据库端调到处理端，然后再一个个看条件是否满足，处理过程无法在数据库端完成。

那么，是否我们应当重新回到关系数据库时代，答案是否定的。对象方式给我们所带来的好处是显而易见的，没有人愿意重新回去写大量的、复杂的、难以理解的sql或者存储过程。对象是对的，问题没有出现在面向对象方面，那么问题出在什么地方呢？问题恰恰出在关系数据库本身，关系数据库与面向对象是不可调和的，要彻底解决问题，只能建立新的面向对象的数据库，或者说，建立一套持久对象的管理系统。

请注意，我们要建立的是持久对象管理系统（在这里，我舍弃了数据库这一概念，以使问题更加明了），该系统应当具备如下功能：

1. 该系统能不间断工作。当我们需要修改某个持久类时，把类从持久对象管理器中下载下来，修改完后，再上传上去，而不用重启管理器。

2. 所有持久对象都应当在持久对象管理器中存活，而不应再转移到其它地方去，要让这些持久对象工作，只能通过消息方式，该消息方式不应当基于RMI等现行的分布式技术，具体的通讯方式以后再描述。

3. 持久对象管理器所管理的一定是对象，持久对象，而不是数据。这主要表现在这些持久对象自己会有行为，而这些行为是在持久对象管理器端执行的，对象不会被转移到其它地方，再执行行为。这些行为包括写行为，也包括读行为。

以上是几点浅显的看法，虽不系统，但至少没有人云亦云。愿与各位愿意思考，愿意找寻真理，而不是整日跟在别人后面捡拾概念的人共勉。

另外，我用java部分实现了上述想法，目前碰到了一些困难，愿与大家共同探讨。