今天拜读了谭云杰先生的博文《面向对象方法中的数据库设计》,确实是受益匪浅。             http://blog.csdn.net/coffeewoo/archive/2010/02/05/5291582.aspx

  在江西微软实训的两次组队项目中，我都是担任数据库设计的角色。NHibernate也接触过一些。照理说应该对数据库设计有些概念了，却没想到我一直都存在着误区。  

  我们一般在需求做得差不多的时候，就开始设计数据库的概念模型。数据库结构确定之后，如果时间不够充裕，就立马开始Coding了。当然，在Coding之前，我们还会习惯性地用动软等第三方工具生成Model层的一堆实体类。因此，我们的Model层实体类与数据库的表往往是一一对应的。也就是说，我们是先设计数据库，后设计类，我们是以数据库设计为核心的。而这种做法，正是谭先生在文中提到的“面向过程的保守派”的做法。

  我之前曾经想过，为什么要鼓吹面向对象呢？对于某些简易的管理信息系统而言，面向对象的优势的确不明显，由于面向过程的思想根深蒂固，在某些项目中，面向过程反而有较高的开发效率。但我现在不得不承认，是自己的眼光太狭隘了。面向对象是以一种比较长远的眼光看待软件。ok,亮出了自己这个反面教材，得秀秀大师的思想了。简言之，就是“面向对象设计解决业务执行逻辑问题，数据库设计解决数据高效的问题”。

  在面向对象中，是没有数据流这一说法的。业务的完成是由对象及消息来完成的，只有“对象流”，没有数据流。    

  只是在现实中，绝大部分的对象持久化是用关系数据库实现的，我们还没有在性能上和查询上可以顶替关系数据库的对象数据库。设计数据库表的目的是不考虑所谓“流”的，考虑的是如何把对象高效的持久化。可以说，数据库设计和之前的面向对象设计是两个领域的问题，面向对象设计解决业务执行逻辑问题，数据库设计解决数据高效的问题（它根本不考虑流控制的概念），它们中间通过OR-mapping的机制结合起来。如果你对此一直有疑问，那说明你试图在设计数据库表时考虑通过数据库表设计表达业务逻辑问题，而不是考虑如何高效的持久化对象。    

  假设，现在技术成熟到我们已经有性能不低于关系数据库的XML持久化机制和对象查询机制，任何对象都可以直接持久化而不需要OR-mapping，那么还需要设计数据库表么？  

  看到此处，我犹如醍醐灌顶。其实我一直认为之前的开发方式有问题，代码写得很别扭，但始终不知问题出在哪里。是的，数据库是关系型的，只能表现一对一、一对多、多对多，而对象间的关系却纷繁复杂得多。我们经常会遇到一个业务对象对应多张表的情况，如果只是单纯地把数据库中的一张表作为一个实体对象，在实现业务层的方法时，自然又得多一道工序。

  所以，我们应关注的是从需求中推导出的对象，而后，再考虑这些对象持久化的方式。事实上，我们的数据库设计最初也是从对象的角度进行考量的（概念模型阶段），但为什么我们没有进行类对象的设计，却转而先设计数据库呢？这倒挺让人玩味的。