关系模型和对象模型的究竟匹配还是不匹配？

我觉得可以理解为规范性和性能之间的一个权衡。在当前硬件条件有限的情况下，牺牲规范来换取性能是必要的。 以电信计费系统来看，基本上2000年前的大的计费系统都是硬编码，设计规范动态计费规则的软件通常都满足不了月末的计费压力（现在情况在发生变化） 现在的我们也许无法想像当年的那些牛人为什么会有如此差劲的设计，但是多考虑当时的背景，当时电信级的服务器性能可能还不如你使用的笔记本呢。这方面有个反例，当年我们有个经理是从IBM过来的，他的一句口头禅就是硬件能解决的问题都不是问题，看看IBM的websphere就知道他们对这句话理解有多深。

第一范式没那么玄乎，只要表的每个字段能对应成一个属性就算满足了。这点可能因为有点太基本，很多人反而不好理解。例如，一个个人资料表里面有个儿女字段，如果保存是按"张三id、李四id”；取出时自己再根据顿号分割得到两个id，那么这种情况违反第一范式，因为儿女这个字段可以再分。
至于主键，在极端情况下就是all-key，也就是全部属性合在一起构成主键。如果两行数据完全相同，那根本就算不上关系数据库了。
所以说，金融、电信类的大项目里，虽然问题很多，但基本还是符合第一范式的。因此可以算满足范式的基本要求。虽然一个字段里需要自己再根据特殊符号进行解析的事情是存在的。

范式主要还是为了解决插入和删除的异常，一般只要不是没法插入或者删除时会把共用信息也给删除，写代码的和维护的都会接受。前者在需要给出主键的值而又给不出来的时候会遇到，后者就靠冗余来补救了。至于字段很多，那估计是逐步逐步演化成那样的。用写dao的技术，形成这种局面是正常的，毕竟操作一张表即使字段和值多一些，也不一定比操作几张表来的麻烦。ms sql的update支持对联和后的表进行修改，得到很多程序员的赞许，也是因为这个道理，虽然语句长一点、字段多一点，但是一条语句就搞定了。

应该说，程序员基本遵守了第一范式，这样保证数据库可以做的下去；而弱化了主键的概念来减少自己在insert时的麻烦；delete的异常一个靠冗余，另一方面通过设置isdelete=true来解决，这样就不会真的发生删除异常；update反正更新几张表和更新多条记录比起来，在写dao的情况下，也还算凑合；至于select，冗余的查起来可能还方便。

不过有了ORM，情况就变了。agile web那本书里面并没有直接给出以数据库为主还是以object为主，但实际上由于activcerecord这个中间层存在，个人认为从哪个角度出发已经都无所谓了。而她所提供的save和分几步查询的这种方式，使得设计朝第三范式靠拢的意义变大。

LZ 的结论:

关系模型和对象模型存在概念上的阻抗不匹配，但是在关系数据库的存储模型上是一致的，无论你从关系模型的三大范式理论出发，还是从对象模型的ORM理论出发，最终一定会得到一致的数据库表设计。

得出一致的数据库表设计这个值得商榷，貌似得到相似的是可能的，因为领域中的基本概念是一致的。比如医院系统中的处方、患者。 从关系模型来看，对象模型来看都会有这些东西。

可是分析的方式是有差别的，也就是说设计的理念，思考的方式差别会导致我们得到最后不一样的东西！
可以做个简单的实验，找个资深的用关系模型设计的开发人员，再找个用对象设计的开发人员，绝对得出不一样的东西！

对象模型与关系模型最大的区别就是继承的概念，也是对象模型为啥比关系模型表达能力更强的根本原因。思考的方式是不一样的。不可以单从数据库最后的表结构来断言这2种思想的差异。


对象模型能否映射到关系模型？当你面对的是关系型设计的表（或者遗留系统的时候）没有ORM工具，而你又想要使用对象模型来封装业务逻辑。那你要干的就是 把对象模型映射到关系模型上。能匹配上么？ 很麻烦！（我正在干这个事情）

关系模型的逻辑能映射到对象模型的数据库中么？ 没有人会干这个吧。

所以结论是： 面向对象设计与关系设计思考方式的不同，会导致不同的模型结果。
             对象模型和关系模型是不一致的，中间需要ORM工具来做一个桥梁。

根据各位2007年的发言，我这样总结和吸收：
1. 期望完全脱离RDM产品从ORM层思考和设计持久层，这也许只是个梦想，或者根本就是个幻想。
   1).任何ORM产品和RDB产品有缝隙，不可能像想象中那么平滑。
   2).斗胆猜测：大家在做项目(数据库类)时的持久层设计肯定是个综合的工作， 补丁式的：Cache, RDB产品，ORM产品样样知识不可缺。(实战内幕有待楼主另开帖)
2. ORM功不可没:
  1).ORM首先的功劳是简化开发代码，OO思考问题。
  2).ORM在性能方面比大部分人想象中做得更好(缓存)
3.三范式未必100%遵从，只要达到系统的目标。

蜷缩在窗口的小沙发上，突然想起王梵志，道是：

我昔未生时
冥冥无所知
天空强生我
生我复何为
无衣使我寒
无食使我饥
还你天公我
还我未生时

谨此纪念我浑噩的2007

所谓的不匹配实际上不在数据的冗余与否，而在于继承和聚合。前者在对象领域是一个extend，后者是一个对象引用。而在数据库领域，两者都需要进行一次join。而数据库三范式确实跟对象设计有很大的共同点，在这一点上我一直把两者统一进行处理，因而所谓的领域模型设计不应该掺合数据表设计的做法我觉得是自己给自己找麻烦，除了这一点，其它的我都认同领域驱动设计。

这个问题有两方面的原因：
一方面是历史遗留问题造成的，只要核心业务系统中出现这种情况，其他依赖其的周边系统必定也会出现类似的情况，到后期积重难返。
另一方面是由于项目"鸿沟"造成的，核心系统中的各个模块由不同的人负责，缺少整体的规划(数据和技术两方面)。这类问题一般都是靠大集中项目来解决，但是目前没有见过特别成功的案例。

PS:高范式和中国式报表存在严重的阻抗不匹配，如果系统中存在大量非报表工具处理的报表，降低范式貌似是最好的选择了。

没看明白，到底是要在领域模型设计的时候考虑数据库表设计还是不考虑。

我觉得数据库表的设计在领域模型设计的时候是不应该考虑的，但是接触过的很多人都很难一下子转变这个思路，结果是设计出的"领域模型"有很多[XX信息]命名的东西。

电信、电力、金融等大型系统出现很多数据库表结构不合理（报表统计涉及表的除外），是由程序设计开发阶段的管理、技术、人员能力等诸多因素造就的.

数据库设计就概念设计而言，就是一个面向对象设计的过程
通过绘制E-R图，拆分关联和属性，逐步范化，基本上就是对象模型的设计过程

个人认为：
大部分“巨表”都是数据库设计没有学好或者图方便而添加的产物
少量的巨表是在条件不允许的情况下不得已的产物

  我怎么记得萨师煊 王珊编写的数据库系统概论,做为我所读的大学的本科计算机专业课教材,其中对范式的描述似乎和robbin所说不太一样哦?

好象说是第一范式(1NF)已经由目前主流的数据库给做了,不符合第一范式,那么根本就不会是关系数据库.也就是说,每个列都是不可再分的数据项.表是二维的.

  理论课没学好呀,实际工作中用冗余字段也用过,觉得换来效率上的提升,在某些情况下还是值得的呀,而又与所学理论课程相矛盾,着实曾经迷茫过一阵子,即使到了现在,由于技术不扎实,也没有个清晰的认识.

我认为如果把 ActiveRecord 和数据库设计放在一起讨论，得出的结果肯定是对象和数据表的设计几乎一致。

原因在于 ActiveRecord 本质上就是以数据库记录为出发点来设计和实现的。ActiveRecord 是将一个数据库记录封装为对象，并且提供一个实现领域逻辑的载体。这样一来，一个 ActiveRecord 对象必然和数据库结构一一对应。

如果一个领域对象无法用简单的数据库结构来表现，那么就没有办法用 ActiveRecord 来实现这个领域对象。

可为什么许多开发者感觉用 ActiveRecord 确实很方便呢？
那是因为他们开发的都是典型的“CRUD“操作应用程序。

比如 JavaEye 这个网站。不会有复杂的业务逻辑，所以也就没有了复杂的对象体系。几乎所有的一切都可以用 ActiveRecord 对应一个数据表来解决。

但如果是 leadyu 提到的应用，复杂的对象体系是必然的设计结果。而且面向接口的架构，又如何能够简单的映射到数据库结构呢？
就像提出 ActiveRecord 模式的 MF 本人所说，一旦一个对象不能找到对应的数据表设计（原文记不清楚了），那么 ActiveRecord 模式就不适合了。

所以楼主所说的“三大范式和我们现在遵循ORM的原则去设计数据库的方式如出一辙”不完全正确。
我想更准确的说法是：“三大范式和我们现在遵循 ActiveRecord 的原则去设计数据库的方式如出一辙”。

最后，我觉得 ActiveRecord 不能和 ORM 划等号。因为 ActiveRecord 的前提就是对象可以找到对应的数据存储结构。这和 ORM 原本打算解决的对象和关系式数据库不匹配问题有巨大的区别。

理想的 ORM 应该不需要对象设计去“迁就”数据库结构。而这一点，ActiveRecord 是做不到的，它要求必须将对象和数据库结构匹配起来。