转自：http://blog.csdn.net/ccat/archive/2009/05/14/4180765.aspx
    几乎每一个新人在初学关系型数据库设计的时候，都会接触到关系范式。但是，我还是见到了大量很离谱的设计。客观的说，背下关系范式，离一个合格的数据库设 计师还差很远。设计工作总是在理想与现实之，规范与工艺之间妥协。建筑如是，造船如是，操作系统设计如是，数据库设计亦如是。
     是的，你记得范式，你还记得反范式建议。你知道范式减少冗余，提高一致性；你还知道反范式可以方便编程。不幸的是，最终的结果总是遵守范式的做法使自己的应用层代码混乱，而反范式的企图使得数据库也陷入混乱。
这是谁的错？
     不必太自责，设计工作是一个经验的积累过程。没有人天生就会做设计。天才与勤奋，是乘法关系。并不是你笨，只是天才对面的那个系数还不够大而已。
     以下的一些经验，或许在你读完关系范式以后，可以抽空看一看 。世上没有魔法，读完这篇文章，并不会立即让你拥有多年设计经验。但是，这些在设计工作中积累的经验教训，应该可以帮助你少走一些弯路。

关于范式

     关系范式并不邪恶，也不要把它想得太神秘，如果书本上的定义不能让你很快理解，不妨试着回答以下的问题：
     字段还可以再分吗？分成两个或更多的字段以后，还能不能表达完整的含义？
     字段的值是不是有限的几个离散的状态？
     两个或若干个字段，能不能提取出来建立为一个数据字典？
     如果表中某个字段依赖其他表，被依赖的字段是不是唯一的（最好是主键）？
     查询中是否会出现超过两个表的Join？

将数据库设计与系统设计结合起来

     数据库设计并不是一个孤立的过程，整个软件生命期中，各方面的工作应该有机结合。这方面我觉得ACCP过去的教材讲得还不错，至少思路是对的：
     在做需求分析的时候，做Use Case。 此时可以分析出应用层的功能接口，对于数据库的实体分类可以有一个大概的划定。例如，这个项目会需要一个工作流，这个项目会需要一个订单系统，或者一个文档库，等等。通常，每个子系统可以对应一个
     在做概要设计的时候，出类关系和ER简图。 通常来说，此时不能确定所有的字段，但是会有哪些表，有哪些主外键依赖，有哪些地方应该需要存储过程和触发器的辅助，等等。
     详细设计时尽可能将数据库结构完全固定。 尽管现代开发工具不断提升XP能力，重构越来越简单。数据库的重构仍然是一件牵一发而动全身的事情，毕竟数据库是信息存储的根本。大厦楼顶加个小花园容易，把地基下面的承重柱子拔出来换两根试试？

重视SQL

     近年来ORM发展很快，几乎每个框架都要提供这个功能，以至于会有些菜鸟认为“ORM”会淘汰SQL语言。
     这是一块试金石，如果你有这样的感觉，应该考虑认真评估一下自己在这个领域是不是太菜了。
     SQL不是一种编程语言这么简单，SQL代表的是一种与应用开发语言完全不同的思想。面向集合，过程无关，着眼于规则定义。可以说，SQL是FP High Order计算的最成功应用，也可以说，SQL是一种静态强类型的MapReduce语言。
看，换上时髦的名词，会不会让你觉得它上等起来了？
     在应用层语言惨烈竞争的同时，SQL语言压倒了同时代出现的其他关系型数据库操作语言，在这个拥有巨大利润的领域占据了绝对统治地位。即使桀骜不驯的 Postgres，也在1995年变身为PostgrSQL。这一过程，并非像VC淘汰BC那么多盘外招，而是长时间争议与选择的结果。
对于信息操作规则定义，SQL几乎是最好的表达方式。接近自然语言，高度可读，并且非常利于优化。
     打个比方，一个基于过程语言的上帝，这样说：
     * 构造一个光源对象
     * 构造一个能源对象
     * 调用光源对象方法，设置能源
     * 调用光源对象的发光方法，传入照明范围内的对象列表
     基于SQL的上帝说，要有光。
     当然，在这位老兄背后，要有打杂的小弟去完成插电点灯的事情，但是作为上帝，什么活都自己做了，要天使干什么？
     看看那些应用层语言的list comprehensions（列表推导式）。不止一次我想要为Python实现一个基于存储层的列表推导式实现，都可耻的失败了。
     当然，我承认这跟跟人能力有关，我不是Gudio。
     看看LINQ，不管如何吹嘘，它就是一个抽象出I/O的SQL。我见过一些人激烈的贬低SQL，抬高ORM，同时又对LINQ顶礼膜拜，这可真够分裂的。
     ORM对应用层编程效率的提升是客观的，无需回避。但是随着你数据操作越来越精细和复杂，就越来越需要通过规则定义来抽象High Order I/O过程。当你转了一圈儿回来，会发现自己又在写SQL。
     想想Hibernate的HQL，想想C#的LINQ。
     计算机不会变魔术。想让它做事更聪明，就需要你这个驭者更加聪明才行。
     好的工具和方法可以给你带来更高的能力系数，但是记住，一个乘法计算，仅有一头大是不够的。
     不懂SQL的人，是不能驾驭好ORM的。

与ORM做朋友

     ORM对于开发工作，无疑是有好处的。我的朋友沈葳说，人脑能组织和分析的事务是有限的，所以代码越短，越有利于提高代码质量。从这个角度讲，ORM是非常重要的开发工具，其意义不亚于C API 函数集到GUI 框架的进步。
要想让ORM充分发挥威力，有时候需要从数据库设计时就做出一定妥协。
     例如，你往往会需要加入自增标识列，会放弃一些精巧但是不利于ORM访问的依赖设定，甚至要放弃一些漂亮的命名（它们在应用层语言中是保留字，但是你用的ORM不懂如何规避）。
     但是，这往往是必要的。就像建筑师向气候和建筑材料妥协一样。
     在ORM默认的自增字段外，也许你还需要基于业务规则的唯一约束，那么额外加索引。
     好的ORM会帮助你方便的查询数据字典，生成对象映射，跟踪数据变更，提供数据完整性的应用层检查，构造两阶段提交事务，减少不必要的I/O。
     同样，不懂得运用ORM，也可能会破坏数据完整性，降低数据访问速度，甚至造成数据库死锁。作为项目开发人员，应该将ORM视为朋友而不是负担。

合理分层

     过去，流行使用复杂的数据库设计，将业务规则存储于数据库的存储过程。现在，又流行抛弃数据层的一切约束，所有的规则都放在应用层。
     这两者都不合理，除了应用需求的影响，前者与Oracle的广告部宣传有关，后者与MySQL阵营的鼓动有关。背后都有一些不合理的力量推动。
每一层应该保证自己的完整性，这才是分层的意义。那么，在数据库层，应该保证数据的完整性。
     数据库备份出来，再恢复进去，应该可以得到所有的业务信息。
     直接向数据库导入数据，应该可以有完整的数据规则保护。
     数据库里保存的，不仅仅是表和记录，应该是完整的持久性信息。
     从这个角度讲，配置文件和应用层代码中不应该有任何业务数据定义，这些信息都应该是数据字典表。如果出现了这种配置文件，大多数情况下都是愚蠢的错误。
     实际上，包括Web网站常见的附件上传，都应该保存在数据库中。
     独立的I/O文件存储、包括将外键约束转移到应用层，往往是因为对性能的妥协。以及，这里面确实存在MySQL阵营在推广过程中的一些不道德的宣传。
     有效利用数据库功能，可以提高应用层的开发速度，简化代码结构，使得数据存储更安全。这通常仰赖与设计人员的经验，根据项目的具体需求进行调整。
     基于这个原则，合理利用数据库功能，编写存储过程，触发器，调校索引，都是必要的。
     我敢打赌，随着MySQL实现越来越多的功能，它的宣传材料上会越来越多的出现以前被MySQL所摒弃的复杂设计理念，并且宣称这是MySQL所独创或一贯倡导的。

收集整理常见的模式

     在设计模式提出这么多年，在关系型数据库问世如此之久后，我很惊讶的一件事就是数据库设计模式仍然是一个相当冷门的领域。实际上，关系数据库的模式也有很多 可循之规。例如用户信息（HR或CRM）、工作流，权限管理（如RBAC），订单等等，都有相当成熟的行业经验和时间，往往只要修改一些字段名，或者在关 键架构的基础上加以扩展，就可以很好的用于实践。
     每一个有志于成为高水平设计人员的开发者，都应该积极的收集自己体会到的数据库设计模式，积极的与同行交流。
     这方面，Oracle的示例Schema，Postgres的示例数据库项目（在Soureforge上可以找到），都是很好的例子。相对来说，微软在MSSQL和Access中提供的示例库更为轻量和简单，也是作为入门的不错借鉴。