数据库设计方法和原则
数据库设计方法和原则
11 个重要的数据库设计规则
来源: 开源中国社区
英文原文： 11 Important Database designing rules
简介
在您开始阅读这篇文章之前，我得明确地告诉您，我并不是一个数据库设计领域的大师。以下列出的 11 点是我对自己在平时项目实践和阅读中学习到的经验总结出来的个人见解。我个人认为它们对我的数据库设计提供了很大的帮助。实属一家之言，欢迎拍砖 : )
我之所以写下这篇这么完整的文章是因为，很多开发者一参与到数据库设计，就会很自然地把 “三范式” 当作银弹一样来使用。他们往往认为遵循这个规范就是数据库设计的唯一标准。由于这种心态，他们往往尽管一路碰壁也会坚持把项目做下去。
如果你对 “三范式” 不清楚，请点击这里（FQ）一步一步的了解什么是“三范式”。
大家都说标准规范是重要的指导方针并且也这么做着，但是把它当作石头上的一块标记来记着（死记硬背）还是会带来麻烦的。以下 11 点是我在数据库设计时最优先考虑的规则。
规则 1：弄清楚将要开发的应用程序是什么性质的（OLTP 还是 OPAP）？
当你要开始设计一个数据库的时候，你应该首先要分析出你为之设计的应用程序是什么类型的，它是 “事务处理型”（Transactional）的还是 “分析型” （Analytical）的？你会发现许多开发人员采用标准化做法去设计数据库，而不考虑目标程序是什么类型的，这样做出来的程序很快就会陷入性能、客户定制化的问题当中。正如前面所说的，这里有两种应用程序类型， “基于事务处理” 和 “基于分析”，下面让我们来了解一下这两种类型究竟说的是什么意思。
事务处理型：这种类型的应用程序，你的最终用户更关注数据的增查改删（CRUD，Creating/Reading/Updating/Deleting）。这种类型更加官方的叫法是 “OLTP” 。
分析型：这种类型的应用程序，你的最终用户更关注数据分析、报表、趋势预测等等功能。这一类的数据库的 “插入” 和 “更新” 操作相对来说是比较少的。它们主要的目的是更加快速地查询、分析数据。这种类型更加官方的叫法是 “OLAP” 。
那么换句话说，如果你认为插入、更新、删除数据这些操作在你的程序中更为突出的话，那就设计一个规范化的表否则的话就去创建一个扁平的、不规范化的数据库结构。
以下这个简单的图表显示了像左边 Names 和Address 这样的简单规范化的表，怎么通过应用不规范化结构来创建一个扁平的表结构。
规则 2：将你的数据按照逻辑意义分成不同的块，让事情做起来更简单
这个规则其实就是 “三范式” 中的第一范式。违反这条规则的一个标志就是，你的查询使用了很多字符串解析函数
例如 substring、charindex等等。若真如此，那就需要应用这条规则了。
比如你看到的下面图片上有一个有学生名字的表，如果你想要查询学生名字中包含“Koirala”，但不包含“Harisingh”的记录，你可以想象一下你将会得到什么样的结果。
所以更好的做法是将这个字段拆分为更深层次的逻辑分块，以便我们的表数据写起来更干净，以及优化查询。
规则 3：不要过度使用 “规则 2”
开发者都是一群很可爱的生物。如果你告诉他们这是一条解决问题的正路，他们就会一直这么做下去，做到过了头导致了一些不必要的后果。这也可以应用于我们刚刚在前面提到的规则2。当你考虑字段分解时，先暂停一下，并且问问你自己是否真的需要这么做。正如所说的，分解应该是要符合逻辑的。
例如，你可以看到电话号码这个字段，你很少会把电话号码的 ISD 代码单独分开来操作（除非你的应用程序要求这么做）。所以一个很明智的决定就是让它保持原样，否则这会带来更多的问题。
规则 4：把重复、不统一的数据当成你最大的敌人来对待
集中那些重复的数据然后重构它们。我个人更加担心的是这些重复数据带来的混乱而不是它们占用了多少磁盘空间。
例如下面这个图表，你可以看到 “5th Standard” 和“Fifth standard” 是一样的意思，它们是重复数据。现在你可能会说是由于那些录入者录入了这些重复的数据或者是差劲的验证程序没有拦住，让这些重复的数据进入到了你的系统。现在，如果你想导出一份将原本在用户眼里十分困惑的数据显示为不同实体数据的报告，该怎么做呢？
解决方法之一是将这些数据完整地移到另外一个主表，然后通过外键引用过来。在下面这个图表中你可以看到我们是如何创建一个名为 “Standards”（课程级别）的主表，然后同样地使用简单的外键连接过去。
规则 5：当心被分隔符分割的数据，它们违反了“字段不可再分”
前面的规则 2 即“第一范式”说的是避免 “重复组” 。下面这个图表作为其中的一个例子解释了 “重复组”是什么样子的。如果你仔细的观察 syllabus（课程）这个字段，会发现在这一个字段里实在是填充了太多的数据了。像这些字段就被称为 “重复组” 了。如果我们又得必须使用这些数据，那么这些查询将会十分复杂并且我也怀疑这些查询会有性能问题。
这些被塞满了分隔符的数据列需要特别注意，并且一个较好的办法是将这些字段移到另外一个表中，使用外键连接过去，同样地以便于更好的管理。
那么，让我们现在就应用规则2（第一范式） “避免重复组” 吧。你可以看到上面这个图表，我创建了一个单独的 syllabus（课程）表，然后使用 “多对多” 关系将它与 subject（科目）表关联起来。
通过这个方法，主表（student 表）的 syllabus（课程）字段就不再有重复数据和分隔符了。
规则 6：当心那些仅仅部分依赖主键的列
留心注意那些仅仅部分依赖主键的列。例如上面这个图表，我们可以看到这个表的主键是 Roll No.+Standard。现在请仔细观察 syllabus 字段，可以看到 syllabus（课程）字段仅仅关联（依赖） Standard（课程级别）字段而不是直接地关联（依赖）某个学生（Roll No. 字段）。
Syllabus（课程）字段关联的是学生正在学习的哪个课程级别（Standard 字段）而不是直接关联到学生本身。那如果明天我们要更新教学大纲（课程）的话还要痛苦地为每个同学也修改一下，这明显是不符合逻辑的（不正常的做法）。更有意义的做法是将这些字段从这个表移到另外一个表，然后将它们与 Standard（课程级别）表关联起来。
你可以看到我们是如何移动 syllabus（课程）字段并且同样地附上 Standard 表。
这条规则只不过是 “三范式” 里的 “第二范式”：“所有字段都必须完整地依赖主键而不是部分依赖”。
规则 7：仔细地选择派生列
如果你正在开发一个 OLTP 型的应用程序，那强制不去使用派生字段会是一个很好的思路，除非有迫切的性能要求，比如经常需要求和、计算的 OLAP 程序，为了性能，这些派生字段就有必要存在了。
通过上面的这个图表，你可以看到 Average 字段是如何依赖 Marks 和Subjects 字段的。这也是冗余的一种形式。因此对于这样的由其他字段得到的字段，需要思考一下它们是否真的有必要存在。
这个规则也被称为 “三范式” 里的第三条：“不应该有依赖于非主键的列” 。我的个人看法是不要盲目地运用这条规则，应该要看实际情况，冗余数据并不总是坏的。如果冗余数据是计算出来的，看看实际情况再来决定是否应用这第三范式。
规则 8：如果性能是关键，不要固执地去避免冗余
不要把 “避免冗余” 当作是一条绝对的规则去遵循。如果对性能有迫切的需求，考虑一下打破常规。常规情况下你需要做多个表的连接操作，而在非常规的情况下这样的多表连接是会大大地降低性能的。
规则 9：多维数据是各种不同数据的聚合
OLAP 项目主要是解决多维数据问题。比如你可以看看下面这个图表，你会想拿到每个国家、每个顾客、每段时期的销售额情况。简单的说你正在看的销售额数据包含了三个维度的交叉。
为这种情况做一个实际的设计是一个更好的办法。简单的说，你可以创建一个简单的主要销售表，它包含了销售额字段，通过外键将其他所有不同维度的表连接起来。
规则 10：将那些具有“键值表”特点的表统一起来设计
很多次我都遇到过这种 “键值表” 。 “名值表” 意味着它有一些键，这些键被其他数据关联着。比如下面这个图表，你可以看到我们有 Currency（货币型）和 Country（国家）这两张表。如果你仔细观察你会发现实际上这些表都只有键和值。
对于这种表，创建一个主要的表，通过一个 Type（类型）字段来区分不同的数据将会更有意义。
规则 11：无限分级结构的数据，引用自己的主键作为外键
我们会经常碰到一些无限父子分级结构的数据（树形结构？）。例如考虑一个多级销售方案的情况，一个销售人员之下可以有多个销售人员。注意到都是 “销售人员” 。也就是说数据本身都是一种。但是层级不同。这时候我们可以引用自己的主键作为外键来表达这种层级关系，从而达成目的。
这篇文章的用意不是叫大家不要遵循范式，而是叫大家不要盲目地遵循范式。根据你的项目性质和需要处理的数据类型来做出正确的选择。
数据库设计14个技巧
1. 原始单据与实体之间的关系
可以是一对一、一对多、多对多的关系。在一般情况下，它们是一对一的关系：即一张原始单据对应且只对应一个实体。
在特殊情况下，它们可能是一对多或多对一的关系，即一张原始单证对应多个实体，或多张原始单证对应一个实体。
这里的实体可以理解为基本表。明确这种对应关系后，对我们设计录入界面大有好处。
〖例1〗：一份员工履历资料，在人力资源信息系统中，就对应三个基本表：员工基本情况表、社会关系表、工作简历表。
这就是“一张原始单证对应多个实体”的典型例子。
2. 主键与外键
一般而言，一个实体不能既无主键又无外键。在E—R 图中, 处于叶子部位的实体, 可以定义主键，也可以不定义主键
(因为它无子孙), 但必须要有外键(因为它有父亲)。
主键与外键的设计，在全局数据库的设计中，占有重要地位。当全局数据库的设计完成以后，有个美国数据库设计专
家说：“键，到处都是键，除了键之外，什么也没有”，这就是他的数据库设计经验之谈，也反映了他对信息系统核
心(数据模型)的高度抽象思想。因为：主键是实体的高度抽象，主键与外键的配对，表示实体之间的连接。
3. 基本表的性质
基本表与中间表、临时表不同，因为它具有如下四个特性：
(1) 原子性。基本表中的字段是不可再分解的。
(2) 原始性。基本表中的记录是原始数据（基础数据）的记录。
(3) 演绎性。由基本表与代码表中的数据，可以派生出所有的输出数据。
(4) 稳定性。基本表的结构是相对稳定的，表中的记录是要长期保存的。
理解基本表的性质后，在设计数据库时，就能将基本表与中间表、临时表区分开来。
4. 范式标准
基本表及其字段之间的关系, 应尽量满足第三范式。但是，满足第三范式的数据库设计，往往不是最好的设计。
为了提高数据库的运行效率，常常需要降低范式标准：适当增加冗余，达到以空间换时间的目的。
〖例2〗：有一张存放商品的基本表，如表1所示。“金额”这个字段的存在，表明该表的设计不满足第三范式，
因为“金额”可以由“单价”乘以“数量”得到，说明“金额”是冗余字段。但是，增加“金额”这个冗余字段，
可以提高查询统计的速度，这就是以空间换时间的作法。
在Rose2002中，规定列有两种类型：数据列和计算列。“金额”这样的列被称为“计算列”，而“单价”和
“数量”这样的列被称为“数据列”。
表1 商品表的表结构
商品名称 商品型号 单价 数量 金额
电视机 29吋 2,500 40 100,000
5. 通俗地理解三个范式
通俗地理解三个范式，对于数据库设计大有好处。在数据库设计中，为了更好地应用三个范式，就必须通俗地理解
三个范式(通俗地理解是够用的理解，并不是最科学最准确的理解)：
第一范式：1NF是对属性的原子性约束，要求属性具有原子性，不可再分解；
第二范式：2NF是对记录的惟一性约束，要求记录有惟一标识，即实体的惟一性；
第三范式：3NF是对字段冗余性的约束，即任何字段不能由其他字段派生出来，它要求字段没有冗余。
没有冗余的数据库设计可以做到。但是，没有冗余的数据库未必是最好的数据库，有时为了提高运行效率，就必须降
低范式标准，适当保留冗余数据。具体做法是：在概念数据模型设计时遵守第三范式，降低范式标准的工作放到物理
数据模型设计时考虑。降低范式就是增加字段，允许冗余。
6. 要善于识别与正确处理多对多的关系
若两个实体之间存在多对多的关系，则应消除这种关系。消除的办法是，在两者之间增加第三个实体。这样，原来一
个多对多的关系，现在变为两个一对多的关系。要将原来两个实体的属性合理地分配到三个实体中去。这里的第三个
实体，实质上是一个较复杂的关系，它对应一张基本表。一般来讲，数据库设计工具不能识别多对多的关系，但能处
理多对多的关系。
〖例3〗：在“图书馆信息系统”中，“图书”是一个实体，“读者”也是一个实体。这两个实体之间的关系，是一
个典型的多对多关系：一本图书在不同时间可以被多个读者借阅，一个读者又可以借多本图书。为此，要在二者之
间增加第三个实体，该实体取名为“借还书”，它的属性为：借还时间、借还标志(0表示借书，1表示还书)，另外，
它还应该有两个外键(“图书”的主键，“读者”的主键)，使它能与“图书”和“读者”连接。
7. 主键PK的取值方法
PK是供程序员使用的表间连接工具，可以是一无物理意义的数字串, 由程序自动加1来实现。也可以是有物理意义
的字段名或字段名的组合。不过前者比后者好。当PK是字段名的组合时，建议字段的个数不要太多，多了不但索引
占用空间大，而且速度也慢。
8. 正确认识数据冗余
主键与外键在多表中的重复出现, 不属于数据冗余，这个概念必须清楚，事实上有许多人还不清楚。非键字段的重
复出现, 才是数据冗余！而且是一种低级冗余，即重复性的冗余。高级冗余不是字段的重复出现，而是字段的派生出现。
〖例4〗：商品中的“单价、数量、金额”三个字段，“金额”就是由“单价”乘以“数量”派生出来的，它就是冗余，
而且是一种高级冗余。冗余的目的是为了提高处理速度。只有低级冗余才会增加数据的不一致性，因为同一数据，可
能从不同时间、地点、角色上多次录入。因此，我们提倡高级冗余(派生性冗余)，反对低级冗余(重复性冗余)。
9. E--R图没有标准答案
信息系统的E--R图没有标准答案，因为它的设计与画法不是惟一的，只要它覆盖了系统需求的业务范围和功能内容，
就是可行的。反之要修改E--R图。尽管它没有惟一的标准答案，并不意味着可以随意设计。好的E—R图的标准是：
结构清晰、关联简洁、实体个数适中、属性分配合理、没有低级冗余。
10 . 视图技术在数据库设计中很有用
与基本表、代码表、中间表不同，视图是一种虚表，它依赖数据源的实表而存在。视图是供程序员使用数据库的
一个窗口，是基表数据综合的一种形式, 是数据处理的一种方法，是用户数据保密的一种手段。为了进行复杂处理、
提高运算速度和节省存储空间, 视图的定义深度一般不得超过三层。 若三层视图仍不够用, 则应在视图上定义临时表,
在临时表上再定义视图。这样反复交迭定义, 视图的深度就不受限制了。
对于某些与国家政治、经济、技术、军事和安全利益有关的信息系统，视图的作用更加重要。这些系统的基本表完
成物理设计之后，立即在基本表上建立第一层视图，这层视图的个数和结构，与基本表的个数和结构是完全相同。
并且规定，所有的程序员，一律只准在视图上操作。只有数据库管理员，带着多个人员共同掌握的“安全钥匙”，
才能直接在基本表上操作。请读者想想：这是为什么？
11. 中间表、报表和临时表
中间表是存放统计数据的表，它是为数据仓库、输出报表或查询结果而设计的，有时它没有主键与外键(数据仓
库除外)。临时表是程序员个人设计的，存放临时记录，为个人所用。基表和中间表由DBA维护，临时表由程序员
自己用程序自动维护。
12. 完整性约束表现在三个方面
域的完整性：用Check来实现约束，在数据库设计工具中，对字段的取值范围进行定义时，有一个Check按钮，通
过它定义字段的值城。
参照完整性：用PK、FK、表级触发器来实现。
用户定义完整性：它是一些业务规则，用存储过程和触发器来实现。
13. 防止数据库设计打补丁的方法是“三少原则”
(1) 一个数据库中表的个数越少越好。只有表的个数少了，才能说明系统的E--R图少而精，去掉了重复的多余的
实体，形成了对客观世界的高度抽象，进行了系统的数据集成，防止了打补丁式的设计；
(2) 一个表中组合主键的字段个数越少越好。因为主键的作用，一是建主键索引，二是做为子表的外键，所以组
合主键的字段个数少了，不仅节省了运行时间，而且节省了索引存储空间；
(3) 一个表中的字段个数越少越好。只有字段的个数少了，才能说明在系统中不存在数据重复，且很少有数据冗
余，更重要的是督促读者学会“列变行”，这样就防止了将子表中的字段拉入到主表中去，在主表中留下许
多空余的字段。所谓“列变行”，就是将主表中的一部分内容拉出去，另外单独建一个子表。这个方法很简
单，有的人就是不习惯、不采纳、不执行。
数据库设计的实用原则是：在数据冗余和处理速度之间找到合适的平衡点。“三少”是一个整体概念，综合观点，
不能孤立某一个原则。该原则是相对的，不是绝对的。“三多”原则肯定是错误的。试想：若覆盖系统同样的功
能，一百个实体(共一千个属性) 的E--R图，肯定比二百个实体(共二千个属性) 的E--R图，要好得多。
提倡“三少”原则，是叫读者学会利用数据库设计技术进行系统的数据集成。数据集成的步骤是将文件系统集成
为应用数据库，将应用数据库集成为主题数据库，将主题数据库集成为全局综合数据库。集成的程度越高，数据
共享性就越强，信息孤岛现象就越少，整个企业信息系统的全局E—R图中实体的个数、主键的个数、属性的个数
就会越少。
提倡“三少”原则的目的，是防止读者利用打补丁技术，不断地对数据库进行增删改，使企业数据库变成了随意
设计数据库表的“垃圾堆”，或数据库表的“大杂院”，最后造成数据库中的基本表、代码表、中间表、临时表
杂乱无章，不计其数，导致企事业单位的信息系统无法维护而瘫痪。
“三多”原则任何人都可以做到，该原则是“打补丁方法”设计数据库的歪理学说。“三少”原则是少而精的
原则，它要求有较高的数据库设计技巧与艺术，不是任何人都能做到的，因为该原则是杜绝用“打补丁方法”
设计数据库的理论依据。
14. 提高数据库运行效率的办法
在给定的系统硬件和系统软件条件下，提高数据库系统的运行效率的办法是：
(1) 在数据库物理设计时，降低范式，增加冗余, 少用触发器, 多用存储过程。
(2) 当计算非常复杂、而且记录条数非常巨大时(例如一千万条)，复杂计算要先在数据库外面，以文件系统方
式用C++语言计算处理完成之后，最后才入库追加到表中去。这是电信计费系统设计的经验。
(3) 发现某个表的记录太多，例如超过一千万条，则要对该表进行水平分割。水平分割的做法是，以该表主键
PK的某个值为界线，将该表的记录水平分割为两个表。若发现某个表的字段太多，例如超过八十个，则
垂直分割该表，将原来的一个表分解为两个表。
(4) 对数据库管理系统DBMS进行系统优化，即优化各种系统参数，如缓冲区个数。
(5) 在使用面向数据的SQL语言进行程序设计时，尽量采取优化算法。
总之，要提高数据库的运行效率，必须从数据库系统级优化、数据库设计级优化、程序实现级优化，这三
个层次上同时下功夫。
上述十四个技巧，是许多人在大量的数据库分析与设计实践中，逐步总结出来的。对于这些经验的运用，读者
不能生帮硬套，死记硬背，而要消化理解，实事求是，灵活掌握。并逐步做到：在应用中发展，在发展中应用。
数据库设计之反规范化
数据库设计简述
数据库设计是把现实世界的商业模型与需求转换成数据库的模型的过程，它是建立数据库应用系统的核心问题。设计的关键是如何使设计的数据库能合理地存储用户的数据，方便用户进行数据处理。
数据库设计完全是人的问题，而不是数据库管理系统的问题。系统不管设计是好是坏，照样运行。数据库设计应当由数据库管理员和系统分析员一起和用户一道工作，了解各个用户的要求，共同为整个数据库做出恰当的、完整的设计。
数据库及其应用的性能和调优都是建立在良好的数据库设计的基础上，数据库的数据是一切操作的基础，如果数据库设计不好，则其它一切调优方法提高数据库性能的效果都是有限的。
数据的规范化
1.1. 范式概述
规范化理论是研究如何将一个不好的关系模式转化为好的关系模式的理论，规范化理论是围绕范式而建立的。规范化理论认为，一个关系数据库中所有的关系，都应满足一定的规范(约束条件)。规范化理论把关系应满足的规范要求分为几级，满足最低要求的一级叫做第一范式(1NF)，在第一范式的基础上提出了第二范式(2NF)，在第二范式的基础上又提出了第三范式(3NF)，以后又提出了BCNF范式，4NF，5NF。范式的等级越高，应满足的约束集条件也越严格。规范的每一级别都依赖于它的前一级别，例如若一个关系模式满足2NF，则一定满足1NF。下面我们只介绍1NF，2NF，3NF范式。
1.2. 1NF
1NF是关系模型的最低要求，它的规则是：
每一列必须是原子的，不能分成多个子列。
每一行和列的位置只能有一个值。
不能具有多值列。
例：如果要求一个学生一行，一个学生可选多门课，则下面的“学生”表就不满足1NF： student(s－no,s－name,class－no)
其中：s－no为学号，s－name为学生姓名，class－no为课程号。因为一个学生可选多门课，所以列class－no有多个值，所以空不符合1NF。
规范化就是把它分成如下两个表：“学生”表和“选课”表，则这两个表就都满足1NF了。
student(s－no,s－name)
stu－class(s－no,class－no)
1.3.2NF
对于满足2NF的表，除满足1NF外，非主码的列必须依赖于所有的主码，而不是组合主码的一部分。如果满足1NF的表的主码只有一列，则它自动满足2NF。
例：下面的“选课”表，不符合2NF。
stu－class(s－no,class－no,class－name)
其中：class－name为课程名称。因为词表的主码是：(s－no,class－no),非主码列class－name依赖于组合主码的一部分class－no,所以它不符合2NF。
对该表规范化也是把它分解成两个表：“选课”表和“课程”表，则它们就都满足2NF了。
stu－class(s－no,class－no)
class(class－no,class－name)
1.4. 3NF
3NF的规则是除满足2NF外，任一非主码列不能依赖于其它非主码列。
例：下面的“课程”表，不符合3NF。
class(class－no,class－name,teacher－no,teacher－name)
其中：teacher－no为任课教师号，teacher－name为任课教师姓名。因为非主码列teacher－name依赖于另一非主码列teacher－no,所以它不符合3NF。
其解决办法也是把它分解成两个表：“课程”表和“教师”表，则它们就都满足3NF了。
class(class－no,class－name,teacher－no)
teacher(teacher－no,teacher－name)
1.5.
小结
当一个表是规范的，则其非主码列依赖于主码列。从关系模型的角度来看，表满足3NF最符合标准，这样的设计容易维护。一个完全规范化的设计并不总能生成最优的性能，因此通常是先按照3NF设计，如果有性能问题，再通过反规范来解决。
数据库中的数据规范化的优点是减少了数据冗余，节约了存储空间，相应逻辑和物理的I/O次数减少，同时加快了增、删、改的速度，但是对完全规范的数据库查询，通常需要更多的连接操作，从而影响查询的速度。因此，有时为了提高某些查询或应用的性能而破坏规范规则，即反规范。
2.数据的反规范
2.1.反规范的好处
是否规范化的程度越高越好?这要根据需要来决定，因为“分离”越深，产生的关系越多，关系过多，连接操作越频繁，而连接操作是最费时间的，特别对以查询为主的数据库应用来说，频繁的连接会影响查询速度。所以，关系有时故意保留成非规范化的，或者规范化以后又反规范了，这样做通常是为了改进性能。例如帐户系统中的“帐户”表B－TB01，它的列busi－balance(企业帐户的总余额)就违反规范，其中的值可以通过下面的查询获得：
selectbusi－code,sum(acc－balance)
from
B－TB06
groupby busi－code
如果B－TB01中没有该列，若想获得busi－name(企业名称)和企业帐户的总余额，则需要做连接操作：
selectbusi－name,sum(acc－balance)
fromB－TB01,B－TB06
whereB－TB01.busi－code=B－TB06.busi－code
groupby busi－code
如果经常做这种查询，则就有必要在B－TB01中加入列busi－balance，相应的代价则是必须在表B－TB06上创建增、删、改的触发器来维护B－TB01表上busi－balance列的值。类似的情况在决策支持系统中经常发生。
反规范的好处是降低连接操作的需求、降低外码和索引的数目，还可能减少表的数目，相应带来的问题是可能出现数据的完整性问题。加快查询速度，但会降低修改速度。因此决定做反规范时，一定要权衡利弊，仔细分析应用的数据存取需求和实际的性能特点，好的索引和其它方法经常能够解决性能问题，而不必采用反规范这种方法。
2.2.常用的反规范技术
在进行反规范操作之前，要充分考虑数据的存取需求、常用表的大小、一些特殊的计算(例如合计)、数据的物理存储位置等。常用的反规范技术有增加冗余列、增加派生列、重新组表和分割表。
2.2.1.增加冗余列
增加冗余列是指在多个表中具有相同的列，它常用来在查询时避免连接操作。例如前面例子中，如果经常检索一门课的任课教师姓名，则需要做class和teacher表的连接查询：
selectclass－name,teacher－name
from
class,teacher
where
class.teacher－no=teacher.teacher－no
这样的话就可以在class表中增加一列teacher－name就不需要连接操作了。
增加冗余列可以在查询时避免连接操作，但它需要更多的磁盘空间，同时增加表维护的工作量。
2.2.2.增加派生列
增加派生列指增加的列来自其它表中的数据，由它们计算生成。它的作用是在查询时减少连接操作，避免使用聚集函数。例如前面所讲的账户系统中的表B－TB01的列busi－balance就是派生列。派生列也具有与冗余列同样的缺点。
2.2.3.重新组表
重新组表指如果许多用户需要查看两个表连接出来的结果数据，则把这两个表重新组成一个表来减少连接而提高性能。例如，用户经常需要同时查看课程号，课程名称，任课教师号，任课教师姓名，则可把表class(class－no,class－name,teacher－no)和表teacher(teacher－no,teacher－name)合并成一个表class(class－no,class－name,teacher－no,teacher－name)。这样可提高性能，但需要更多的磁盘空间，同时也损失了数据在概念上的独立性。
2.2.4.分割表
有时对表做分割可以提高性能。表分割有两种方式：
1水平分割：根据一列或多列数据的值把数据行放到两个独立的表中。
水平分割通常在下面的情况下使用:A 表很大，分割后可以降低在查询时需要读的数据和索引的页数，同时也降低了索引的层数，提高查询速度。B 表中的数据本来就有独立性，例如表中分别记录各个地区的数据或不同时期的数据，特别是有些数据常用，而另外一些数据不常用。C 需要把数据存放到多个介质上。
例如法规表law就可以分成两个表active－law和inactive－law。activea－authors表中的内容是正生效的法规，是经常使用的，而inactive－law表则使已经作废的法规，不常被查询。水平分割会给应用增加复杂度，它通常在查询时需要多个表名，查询所有数据需要union操作。在许多数据库应用中，这种复杂性会超过它带来的优点，因为只要索引关键字不大，则在索引用于查询时，表中增加两到三倍数据量，查询时也就增加读一个索引层的磁盘次数。
2垂直分割：把主码和一些列放到一个表，然后把主码和另外的列放到另一个表中。如果一个表中某些列常用，而另外一些列不常用，则可以采用垂直分割，另外垂直分割可以使得数据行变小，一个数据页就能存放更多的数据，在查询时就会减少I/O次数。其缺点是需要管理冗余列，查询所有数据需要join操作。
3.反规范技术需要维护数据的完整性
无论使用何种反规范技术，都需要一定的管理来维护数据的完整性，常用的方法是批处理维护、应用逻辑和触发器。批处理维护是指对复制列或派生列的修改积累一定的时间后，运行一批处理作业或存储过程对复制或派生列进行修改，这只能在对实时性要求不高的情况下使用。数据的完整性也可由应用逻辑来实现，这就要求必须在同一事务中对所有涉及的表进行增、删、改操作。用应用逻辑来实现数据的完整性风险较大，因为同一逻辑必须在所有的应用中使用和维护，容易遗漏，特别是在需求变化时，不易于维护。另一种方式就是使用触发器，对数据的任何修改立即触发对复制列或派生列的相应修改。触发器是实时的，而且相应的处理逻辑只在一个地方出现，易于维护。一般来说，是解决这类问题的最好的办法。
4.结束语
数据库的反规范设计可以提高查询性能。常用的反规范技术有增加冗余列、增加派生列、重新组表和分割表。但反规范技术需要维护数据的完整性。因此在做反规范时，一定要权衡利弊，仔细分析应用的数据存取需求和实际的性能特点。
数据表设计原则
1)不应该针对整个系统进行数据库设计，而应该根据系统架构中的组件划分，针对每个组件所处理的业务进行组件单元的数据库设计；不同组件间所对应的数据库表之间的关联应尽可能减少，如果不同组件间的表需要外键关联也尽量不要创建外键关联，而只是记录关联表的一个主键，确保组件对应的表之间的独立性，为系统或表结构的重构提供可能性。
2)采用领域模型驱动的方式和自顶向下的思路进行数据库设计，首先分析系统业务，根据职责定义对象。对象要符合封装的特性，确保与职责相关的数据项被定义在一个对象之内，这些数据项能够完整描述该职责，不会出现职责描述缺失。并且一个对象有且只有一项职责，如果一个对象要负责两个或两个以上的职责，应进行分拆。
3)根据建立的领域模型进行数据库表的映射，此时应参考数据库设计第二范式：一个表中的所有非关键字属性都依赖于整个关键字。关键字可以是一个属性，也可以是多个属性的集合，不论那种方式，都应确保关键字能够保证唯一性。在确定关键字时，应保证关键字不会参与业务且不会出现更新异常，这时，最优解决方案为采用一个自增数值型属性或一个随机字符串作为表的关键字。
4)由于第一点所述的领域模型驱动的方式设计数据库表结构，领域模型中的每一个对象只有一项职责，所以对象中的数据项不存在传递依赖，所以，这种思路的数据库表结构设计从一开始即满足第三范式：一个表应满足第二范式，且属性间不存在传递依赖。
5)同样，由于对象职责的单一性以及对象之间的关系反映的是业务逻辑之间的关系，所以在领域模型中的对象存在主对象和从对象之分，从对象是从1－N或N－N的角度进一步主对象的业务逻辑，所以从对象及对象关系映射为的表及表关联关系不存在删除和插入异常。
6)在映射后得出的数据库表结构中，应再根据第四范式进行进一步修改，确保不存在多值依赖。这时，应根据反向工程的思路反馈给领域模型。如果表结构中存在多值依赖，则证明领域模型中的对象具有至少两个以上的职责，应根据第一条进行设计修正。第四范式：一个表如果满足BCNF，不应存在多值依赖。
7)在经过分析后确认所有的表都满足二、三、四范式的情况下，表和表之间的关联尽量采用弱关联以便于对表字段和表结构的调整和重构。并且，我认为数据库中的表是用来持久化一个对象实例在特定时间及特定条件下的状态的，只是一个存储介质，所以，表和表之间也不应用强关联来表述业务（数据间的一致性），这一职责应由系统的逻辑层来保证，这种方式也确保了系统对于不正确数据（脏数据）的兼容性。当然，从整个系统的角度来说我们还是要尽最大努力确保系统不会产生脏数据，单从另一个角度来说，脏数据的产生在一定程度上也是不可避免的，我们也要保证系统对这种情况的容错性。这是一个折中的方案。
8)应针对所有表的主键和外键建立索引，有针对性的（针对一些大数据量和常用检索方式）建立组合属性的索引，提高检索效率。虽然建立索引会消耗部分系统资源，但比较起在检索时搜索整张表中的数据尤其时表中的数据量较大时所带来的性能影响，以及无索引时的排序操作所带来的性能影响，这种方式仍然是值得提倡的。
9)尽量少采用存储过程，目前已经有很多技术可以替代存储过程的功能如“对象/关系映射”等，将数据一致性的保证放在数据库中，无论对于版本控制、开发和部署、以及数据库的迁移都会带来很大的影响。但不可否认，存储过程具有性能上的优势，所以，当系统可使用的硬件不会得到提升而性能又是非常重要的质量属性时，可经过平衡考虑选用存储过程。
10)当处理表间的关联约束所付出的代价（常常是使用性上的代价）超过了保证不会出现修改、删除、更改异常所付出的代价，并且数据冗余也不是主要的问题时，表设计可以不符合四个范式。四个范式确保了不会出现异常，但也可能由此导致过于纯洁的设计，使得表结构难于使用，所以在设计时需要进行综合判断，但首先确保符合四个范式，然后再进行精化修正是刚刚进入数据库设计领域时可以采用的最好办法。
11)设计出的表要具有较好的使用性，主要体现在查询时是否需要关联多张表且还需使用复杂的SQL技巧。
12)设计出的表要尽可能减少数据冗余，确保数据的准确性，有效的控制冗余有助于提高数据库的性能。
2 表设计
3 视图设计
4 存储过程设计
ORM与存储过程
相关概念：
1.1 实体框架（EF）是一个对象关系映射器，使.NET开发人员使用特定于域的对象与关系数据。它消除了需要开发人员通常需要编写的大部分数据访问代码。简化了原有的ado.net数据访问方式。 ORM是通过使用描述对象和数据库之间映射的元数据，将程序中的对象自动持久化到关系数据库中。
1.2 在C#中常用的ORM框架有：
1.NHibernate（从java的Hibernate延伸过来）
2.Linq to SQL类（只针对MSSQL数据库的）
3.Entity FrameWork（微软的一个开源的ORM，可以针对多种主流数据库（如MSSQL、MySql、Oracle等））
ADO.NET的名称起源于ADO（ActiveX Data Objects），是一个COM组件库，用于在以往的Microsoft技术中访问数据。之所以使用ADO.NET名称，是因为Microsoft希望表明，这是在NET编程环境中优先使用的数据访问接口。
传统面向过程的程序设计
传统的系统设计都是自底向上的，先设计数据库表，然后在这之上对数据库表进行进一步封装，设计了视图、存储过程和函数，然后应用程序开发人员就只能针对这层封装进一步编写上层的业务逻辑，在往上继续编写显示层。
存储过程Procedure是一组为了完成特定功能的SQL语句集合，经编译后存储在数据库中，用户通过指定存储过程的名称并给出参数来执行。存储过程中可以包含逻辑控制语句和数据操纵语句，它可以接受参数、输出参数、返回单个或多个结果集以及返回值。
存储过程有很多优点：
1.存储过程允许标准组件式编程存储过程创建后可以在程序中被多次调用执行，而不必重新编写该存储过程的SQL语句。而且数据库专业人员可以随时对存储过程进行修改，但对应用程序源代码却毫无影响，从而极大的提高了程序的可移植性。
2.存储过程能够实现较快的执行速度如果某一操作包含大量的T-SQL语句代码，分别被多次执行，那么存储过程要比批处理的执行速度快得多。因为存储过程是预编译的，在首次运行一个存储过程时，查询优化器对其进行分析、优化并给出最终被存在系统表中的存储计划。而批处理的T-SQL语句每次运行都需要预编译和优化，所以速度就要慢一些。
3.存储过程减轻网络流量对于同一个针对数据库对象的操作，如果这一操作所涉及到的T-SQL语句被组织成一存储过程，那么当在客户机上调用该存储过程时，网络中传递的只是该调用语句，否则将会是多条SQL语句。从而减轻了网络流量，降低了网络负载。
4.存储过程可被作为一种安全机制来充分利用系统管理员可以对执行的某一个存储过程进行权限限制，从而能够实现对某些数据访问的限制，避免非授权用户对数据的访问，保证数据的安全。
1.在生产环境下，可以通过直接修改存储过程的方式修改业务逻辑（或bug），而不用重启服务器。但这一点便利被许多人滥用了。有人直接就在正式服务器上修改存储过程，而没有经过完整的测试，后果非常严重。
2.执行速度快。存储过程经过编译之后会比单独一条一条执行要快。但这个效率真是没太大影响。如果是要做大数据量的导入、同步，我们可以用其它手段。
3.减少网络传输。存储过程直接就在数据库服务器上跑，所有的数据访问都在服务器内部进行，不需要传输数据到其它终端。但我们的应付服务器通常与数据库是在同一内网，大数据的访问的瓶颈会是硬盘的速度，而不是网速。
4.能够解决presentation与数据之间的差异，说得文艺青年点就是解决OO模型与二维数据持久化之间的阻抗。领域模型和数据模型的设计可能不是同一个人（一个是SA，另一个是DBA），两者的分歧可能会很大——这不奇怪，一个是以OO的思想来设计，一个是结构化的数据来设计，大家互不妥协——你说为了软件的弹性必须这么设计，他说为了效率必须那样设计，为了抹平鸿沟，就用存储过程来做数据存储的逻辑映射（把属性映射到字段）。好吧，台下已经有同学在叨咕ORM了。
5.方便DBA优化。所有的SQL集中在一个地方，DBA会很高兴。这一点算是ORM的软肋。不过按照CQRS框架的思想，查询是用存储过程还是ORM，还真不是问题——DBA对数据库的优化，ORM一样会受益。况且放在ORM中还能用二级缓存，有些时候效率还会更高。
存储过程的使用是非常广泛的。
但是大量使用存储过程这种方式有很多缺点：
如果关注过微软出的一些示例程序，发现都是把复杂的业务逻辑放在存储过程中，中间层只要简单调用一下这个存储过程就可以了，代码看起来非常清爽整洁。但许多人认为(包括我)，它有几个缺点：
a）过于依赖数据库，甚至可以说，这种开发方式，基本上在微软的特定数据库上绑定死了。也可以说，这种开发方式的出发点，很大程度上是有利于微软的商业利益的。
b）存储过程不利于维护和业务逻辑的复用、分解和重构。你是数据库高手，也许不觉得什么，但对于水平不等的其他程序员，维护或调试修改其他人的存储过程，往往是一场灾难。
c）虽然存储过程的重要优点，是提高性能，但在实际场景中的后果却是阻碍了性能。具体讲，相对于sql，存储过程虽然有那么一些性能优势，但因为绑定死了特定数据库，反而不利于数据库的垂直分区和水平分区。同时，海量数据下，大量使用nosql数据库(非关系型数据库)等其他方式的存储，已经是必经之路，存储过程成了这方面巨大的障碍。
最后，我觉得ORM应该是一个必备工具，但它不能代替原生的数据库操作，在复杂的查询需求下，sql或存储过程还是很有必要的。我觉得以ORM为主，辅之以sql或存储过程，是比较实用的策略。
1.SQL本身是一种结构化查询语言，加上了一些控制（赋值、循环和异常处理等），但不是OO的，本质上还是过程化的，面对复杂的业务逻辑，过程化的处理会很吃力。这一点算致命伤。
2.不便于调试。基本上没有较好的调试器，很多时候是用print来调试，但用这种方法调试长达数百行的存储过程简直是噩梦。好吧，这一点不算啥，C#/java一样能写出噩梦般的代码。
3.没办法应用缓存。虽然有全局临时表之类的方法可以做缓存，但同样加重了数据库的负担。如果缓存并发严重，经常要加锁，那效率实在堪忧。
4.无法适应数据库的切割（水平或垂直切割）。数据库切割之后，存储过程并不清楚数据存储在哪个数据库中。
5.精通SQL的新手越来越少——不要笑，这是真的，我面试过N多新人，都不知道如何创建全局临时表、不知道having、不知道聚集索引和非聚集索引，更别提游标和提交叉表查询了。好吧，这个缺点算是凑数用的，作为屌丝程序员，我们的口号是：没有不会的，只有不用的。除了少数有语言洁癖的人，我相信精通SQL只是时间问题。
总结
存储过程最大的优点是部署的方便性——可以在生产环境下直接修改——虽然滥用的后果很严重。
存储过程最大的缺点是SQL语言本身的局限性——我们不应该用存储过程处理复杂的业务逻辑——让SQL回归它“结构化查询语言”的功用吧。
首先谈谈存储过程使用的误区，使用存储过程架构的人以为可以解决性能问题，其实它正是导致性能问题的罪魁祸首之一，打个比喻：如果一个人频临死亡，打一针可以让其延长半年，但是打了这针，其他所有医疗方案就全部失效，请问你会使用这种短视方案吗？
为什么这样说呢？如果存储过程都封装了业务过程，那么运行负载都集中在数据库端，要中间J2EE应用服务器干什么？要中间服务器的分布式计算和集群能力做什么？只能回到过去集中式数据库主机时代。现在软件都是面向互联网的，不象过去那样局限在一个小局域网，多用户并发访问量都是无法确定和衡量，依靠一台数据库主机显然是不能够承受这样恶劣的用户访问环境的。（当然搞数据库集群也只是五十步和百步的区别）。
面向对象的程序设计
随着面向对象开发兴起，人们发现面向数据库和面向对象思维方面不太一致，匹配有障碍。就出现了ORM，希望以面向对象化的思维、领域驱动模型设计方法来设计程序，然后通过这个ORM工具，映射到关系数据库中。
ORM的目的，就是先设计对象，然后再映射到关系数据库，终极目标就是希望软件开发的过程，完全以面向对象的方式来设计。一个完美的ORM，可以让开发者都不会数据库知识。当然，终极目标和完美境界，都是不存在的。
2）实际的作用
ORM在实际开发中带来的帮助，我觉得主要还不是面向对象的设计方式的变革，而是它作为一个引入的中间层，带来了额外的好处：
a）大多数数据库操作都更加方便简单了（许多人都离不开ORM，就是因为极度的方便）
b）屏蔽了数据库的差别，可以支持多种数据库
c）更不容易犯数据库操作中的一些低级错误，比如重复的sql查询、比如大量的注入攻击漏洞等等
……
Orm好处：
ORM为了解决程序开发中处理的对象格式与关系数据库的数据零散格式之间的“阻抗不匹配”问题。当然它可以集成一些近些年最新的框架知识，但是它肯定不是单纯地为了得到“最高操作效率”的目的的。你永远都能用低级的手段得到“最高操作效率”。所以没有谁在使用EF的时候禁止你同时使用ADO.NET。
你想到一个sql表达式可能非常复杂的时候，你肯定需要同时使用ADO.NET和EF两个版本来进行研究。而一般来说，新手几乎都会感兴趣于EF，这是你阻挡不了的。这就好像有人强调c语言程序如果写得好的话、永远都比c#程序（可能）运行得更快，然而我们其实都知道c程序员做现代高级语言的程序猿的工作是多么慢、项目缺乏扩展张力。
一个ORM并不需要每一次运行都翻译sql语句，它可以仅仅翻译一次然后就重复使用，甚至可以把上一进程的翻译结果保存到当前磁盘中让下一个进程在启动时先读取。同样地，就算EF是反射的（而实际它是自动生成代码的），那么也仅需要反射一次然后就把内存中生成的操作过程做为委托而重复调用。
我不用EF主要有两个原因。其一是因为它不能直接支持多态，其二是因为以前它不支持CodeFirst模式（现在也不太给力）。不过我认为它一直在改进。只不过我现在不用关系数据库了，一直没有精力去研究其编程的最佳实践、性能陷阱而已。
EF应该提供更多更好的编程实践，来避免一些容易滥用的陷阱。但是对于 .net 程序员而言，应该知道的关于性能的东西很多（例如善用缓存、业务架构设计、前端编程而不是服务器编程，等等），把一切性能问题都归咎到查询数据库的几条代码上，这其实可能是在事业上的一个“没有发展”的表现。
开发效率
易于维护
支持多种类型数据库
面向对象程序开发，不需要了解数据库细节
ORM的四个核心理念来认识它：
· 简单：ORM以最基本的形式建模数据。比如ORM会将MySQL的一张表映射成一个PHP类（模型），表的字段就是这个类的成员变量
· 精确：ORM使所有的MySQL数据表都按照统一的标准精确地映射成PHP类，使系统在代码层面保持准确统一
· 易懂：ORM使数据库结构文档化。比如MySQL数据库就被ORM转换为了PHP程序员可以读懂的PHP类，PHP程序员可以只把注意力放在他擅长的PHP层面（当然能够熟练掌握MySQL更好）
· 易用：ORM的避免了不规范、冗余、风格不统一的SQL语句，可以避免很多人为Bug，方便编码风格的统一和后期维护
ORM一般都针对数据模型提供了一下常见的接口函数，比如：create(), update(), save(), load(), find(), find_all(), where()等，也就是讲sql查询全部封装成了编程语言中的函数，通过函数的链式组合生成最终的SQL语句。
所以由这些来看，ORM对于敏捷开发和团队合作开发来说，好处是非常非常大的。这里就罗列一下我想到的ORM显著的优点：
· 大大缩短了程序员的编码时间，减少甚至免除了对Model的编码
· 良好的数据库操作接口，使编码难度降低，使团队成员的代码变得简洁易读、风格统一
· 动态的数据表映射，在数据表结构甚至数据库发生改变时，减少了相应的代码修改
· 减少了程序员对数据库的学习成本
· 可以很方便地引入数据缓存之类的附加功能
但是ORM并不是一个完美的东西，它同时也有其自身不可避免的缺点：
· 自动化进行关系数据库的映射需要消耗系统性能。其实这里的性能消耗还好啦，一般来说都可以忽略之，特别是有cacha存在的时候
· 在处理多表联查、where条件复杂之类的查询时，ORM的语法会变得复杂且猥琐
· 越是功能强大的ORM越是消耗内存，因为一个ORM Object会带有很多成员变量和成员函数。有一次修复bug时就遇见，使用ORM查询的时候会占用12MB的内存，而使用SQL的查询时只占用了1.7MB……
对于一般的Web应用开发来说，使用ORM确实能带来上述的诸多好处，而且在大部分情况下涉及不到ORM的不好的地方。但是在系统里面有大数据量、大运算量、复杂查询的地方，就不要用ORM。ORM的性能问题将给你带来灾难。在这些地方就可以使用纯SQL或者其他简单轻量的DB Helper库了。在详细了解ORM之后，你就可以扬长避短让ORM发挥其最大效用了。
Orm缺点：
而在实际开发中，缺点也很明显，就是关系数据库最擅长的复杂查询，ORM明显力不从心，不仅仅是wojilu ORM，凡是有经验的ORM使用者，比如hibernate方面的开发人员，一般也不会用ORM做复杂的查询。
ORM之硬伤
园子里有些人，他们真以为自己明白了面向对象，然后装着满腹经纶，侃侃而谈，一篇接一篇，不厌其烦地喊着ORM如何如何。你以为他真的明白“面向对象”么？其实，他对面向对象的理解仅限于教科书中的封装、继承和多态，或者再知道一点面向对象的若干原则但其实并不真正理解。
笔者愚钝，入行多年尚不懂面向对象，只懂得用其形而不懂用其实。五年后的某一天终于开窍，明白了面向对象之实，也仅仅是一个开始而已。当又经历了另一个五年的倦怠，发现并理解了设计模式、面向方面等技术作为面向对象的必要补充后，才算是彻悟！所以当我见过一个同学，尚未出校门已然彻悟，真是羞愧！
有一天面试的时候，我问一位同学，Framework和Library的区别是什么？他答不上来。而另一个同学略一思考就告诉我，你的程序会调用Library，而Framework会调用你的程序。虽然精辟，但我还是要补充：Framework通常也会提供一个Library，所以，Library是水平的，而Framework是垂直的，此处的“水平”和“垂直”是相对应用系统的层次设计而言的。如果没有层次，其实Framework其实就是Library。Microsoft的Enterprise Library当然就是一个Library，无法代替Framework。
如果让那位已经彻悟的同学舍弃ORM来实现复杂的业务功能，他当然无法接受。相反，如果让一位抱着《Thinking inJava》似懂非懂的同学用ORM来实现同样的功能，他也一样无法接受。其中的一些同学非常擅于“鸡蛋里挑骨头”，于是园子里有了这样一堆垃圾文章或者垃圾跟贴。另外一些同学不精于这样的能力，所以仍在徬徨之中。
此乃ORM惟一之硬伤也！如果你不理解面向对象思想，就先试着去理解，然后再来讨论ORM这个话题，并发表你的高见。
再说性能
ORM提供了所有SQL语句的生成，代码人员远离了数据库概念。从一个概念需求(例如一个HQL)映射为一个SQL语句，并不需要什么代价，连1%的性能损失都没有。真正的性能损失在映射过程中，更具体地讲，是在对象实例化的过程中。我曾经做过一个试验，以“计算第N个素数”这样的命题。我采用Delphi写Native Win32 Console程序，又采用C#写CLR Console程序。两者相比，令我大失所望。
| N |
结果 |
耗时 |
|
| Delphi |
C# |
||
| 1000 |
7927 |
0ms |
2ms |
| 10000 |
104743 |
16ms |
17ms |
| 100000 |
1299721 |
438ms |
324ms |
| 1000000 |
15485867 |
11437ms |
7823ms |
该命题采用的算法是找出第N个素数以前的所有素数，开辟一个内存区存贮这些素数。在Delphi中我用链表，在C#中我用List
不知道各位是否已经明白了性能在哪儿损失了：内存分配。Native的内存分配与释放都是非常耗时的操作系统行为。但在托管环境下，内存的释放是GC干的事情，甚至不需要统计到耗时中，而内存的分配也是一件非常快捷的事情。当然，即使是快捷也还是需要耗时的。这让我联想到DataSet的性能。DataSet也是一种数据容器，但是却没有多少人抱怨DataSet的性能。如果你明白DataSet的机制，就会发现，DataStorage巧妙地规避了内存分配和耗时的问题。而我们的ORM无法解决每个对象实例在构造时分配内存所耗时间。我做了一个不精确的评估，相比DataSet，对象集合的性能损失大约占20%左右。
如果假定ORM并没有比传统的数据访问方式耗费额外的IO的话，除此之外，ORM再没有任何性能损失！
再回到前提条件：ORM并没有比传统的数据访问方式耗费额外的IO。这个条件成立么？
“由于ORM的实体对象定义已经固定，所以即使我不需要某些字段，也一样需要加载这些字段。”
OK，有的同学已经看出来了。额外定义一个视图的实体对象即可。定义这些视图的实体对象的确很麻烦，但是肯定比构造那些SQL并不断地维护它简单得多。
“当一张表中有1000万行数据时，实例化1000万个对象是不可能的。”
非常正确。难道你曾经成功地尝试过将1000万行数据加载到某个DataTable中并且没有性能问题？从应用的角度来说，在一个模型中包含的实例数超过500行就有设计不当的嫌疑。我对Google的抱怨是：当搜索结果超过1000个时都会令我抓狂。让我从1000行数据中找出我所需要的某一行，这是开发人员的思维，并不是用户的思维。如果能够在已有的结果中进行二次、三次或者多次进一步的筛选，可能更适合绝大多数人。我为什么不愿意在分页中花太多的精力，其原因也是如此。我认为用户的眼球只能接受100行以内的数据，超过这个行数就需要采用其它的方式，或者改善领域设计。所以，这个问题的答案是：你不可能需要一次载入1000万行。
“当应用系统整体性能欠佳时，因为隐藏了数据访问细节，从而无法找到快速优化的途径。”
不能同意。几乎每一个ORM框架都提供了非常可靠的数据库访问日志。通过这些日志分析性能损失将比直接使用SQL语句更可靠、更方便。
灵活性
ORM不够灵活？我完全不能理解，我甚至不知道这个不够灵活是与什么基准相比。相反，ORM可以让你灵活地替换数据库(当然这个优点并没有非常重要的意义)；在修改数据库以后不需要修改服务层或者只需要进行简单的修改；可以对某个服务进行单独的测试；可以对服务进行不依赖数据库的、上下文一级的扩展；可以进行更好的层次设计；......
不能实现所有的查询条件
如果是想表达“每一个Select语句可以通过面向对象的方式进行查询”的话，我觉得目前绝大部分ORM框架都已经很好地解决。我解决这一问题的基础是：我不提供超越SQL ANSI92的能力，但覆盖SQL ANSI92的所有功能。对于解决实际应用中的不足部分，采用运行时算法补充。Hibernate采用的是HQL这样的方式，基本上SQL能够做到的，HQL都无一例外可以做到。ECO采用的是OCL的方式，其功能可以完全覆盖SQL。我的框架所实现的查询目前我还没有发现无法解决并必须利用Native SQL来实现的(因此我无法理解Hibernate3为什么要提供这样的扩展)。Hibernate采用的策略是以面向对象为核心，换句话说，以持久化对象为终极目标，而以加载对象以持久化对象为前提。设计一个POJO，实例化，然后保存起来，下次使用的时候可以依样载入即可。大规模的查询并不是框架的核心目标。所以，如果你完全依赖Hibernate去持久化，我非常担心你将来是否有机会用你的数据积累去做数据仓库。而我的框架目标则不同。在持久化与加载两个目标间我没有主次之分。我也没有超前到MDA，我的对象模型仍然基于数据库的ER设计，我仍然提供一组非常清晰明了的数据库视图。
多表连接查询
如果需要将多表的连接查询结果转换成一个二维视图，显然需要你再定义另一个视图实体对象，将视图映射到对象模型。如果你仅仅是要在一个对象实例的某个属性中获得另外一个对象的集合，似乎这不是DAL方式的优势，而反而是ORM的优势。将多个对象所依赖的多个对象放到同一个上下文中，显然这是最好的一种方式。
统计查询
从理论上讲，ORM不适合做OLAP，不适合做太多统计查询。其实这一点，我的框架已经提供了非常好的解决方案，对Aggregate到面向对象的视图处理得非常好。
开发效率
提高开发效率仅仅是一个抽象的目标，具体的手段应该是两个方面：一是IDE和辅助工具；一是适合将任务分解成多个解耦的部分从而可以通过增加人员来提升总的开发效率。虽然ORM仅仅是开发环节中很小的一部分，但是却遍布应用系统中的每一角落，因而对开发效率影响较大。除了ORM，难道还有更好的选择么？
ORM后，原来精湛的SQL技能变得毫无用武之地，让人甚是失落，但这并不是ORM的过错。
# re: ORM之硬伤 2007-01-07 13:59 Zhongkeruanjian
ORM也有自己的适用范围，并不是所有的系统都得用ORM。就像面向对象的语言的产生是为了解决越拉越庞大的软件系统的复杂性，扩展性和复用性。而基于操作系统的软件（驱动等）它肯定不适合一样。ORM也不能解决所有的问题。它有它自己的适用范围。
即使是这样，在一个非常适合于ORM的系统里，也必须考虑很多问题，举个例子：
我们都知道ORM是将数据库的记录映射成实体，它不会像SQL那样可以灵活的取某一，两个字段（当然ORM也可以，比如NH中的投影映射，不过这是相当的别扭）。那么我们在作设计时，必须要避免某些情况，比如，数据库的列的内容要尽量的少，我曾经见过有人将数据库某个表中加了个IMAGE字段，而几乎每行都有IMAGE的存储，少则1，2M，多则10M，而这个字段几乎很少在业务逻辑中用到（附件），然后抱怨ORM性能太差。这时候，你就必须考虑将image放在文件系统中，而在数据库中存个路径就OK。（当然，HIBERNATE有某一字段的延迟加载，NET这边还没有这个功能，即便是这样，也不是万能的，比如在Remoting系统里，延迟加载统统失效）。
# re: ORM之硬伤 2007-01-07 14:10 Teddy'sKnowledge Base
精炼！几乎找不出论证过程中的任何破绽！
orm思想永远没错，但现实的项目情况，往往不是论证中的那么完美。可能是使用orm的程序员的个人能力问题；也有可能是，项目必须基于db到oo，不允许再从oo到db；或者构架师选择了一个不像“kanas”那么完美的orm实现，或者，程序员对于所用的orm组件的使用不熟悉，等等等等都有可能让项目陷入困境。那么谁来救救这些项目？
和任何新技术新思想一样，orm在解决了很多问题同时，也不可避免会带来新的问题和新的成本。很多时候大家作选择时，不完全是（甚至更大程度上不是）出于技术本身的优劣、或者优雅，而是出于成本。
最后一个大家都十分关心问题：.net 2.0的kanas本月能按时发布吗？
# re: ORM之硬伤 2007-01-07 14:12 midea0978
至今还没有看到一个大型的成功的MIS系统架构在ORM之上的，往往是一些很小的WEB应用成了某些狂热爱好者的试验田。楼主做过几个成功的ORM项目呢
oracle 11i、sap如果也是用的ORM，就服了。
就像很多人叫UML怎么好，结果整出来文档的给用户看是一抹黑，通常也只是在打单的时候宣称，真正项目开始时，不了了之，用得好的少得很。
很多人会说，你不懂，懂得人少就用不起来，是认识的问题，但是一个东西这么难认识的时候，也就只能是停留在纸面讨论了。
你看struts，这么简单实用，哪个项目都看得到影子，这种框架才叫好的框架，EJB，有几个人用好了？ 回复 更多评论
# re: ORM之硬伤 2007-01-07 14:28 阿水
ORM 的宗旨就是OO来解决业务规则问题，但是关系数据库
已经存在很多年，很多基于DB的技术都很成熟，个人认为
ORM只是 为了OO而使用的妥协折中的方法，绝对不是什么
了不起 也不是必须用的东西
如果 你处理过很多复杂业务规则，多层游标 大概就知道我的意思
我曾经试图把一个很复杂的 存储过程 用OO的方式 实现
姑且不论 性能问题 首先并发就要命 而且 实现起来 几乎到
后来 就写不下去了 需要 大概 10几个类 每个类都有 很多方法
可是 原来用存储过程 也就 400 多行 当然 我最后没有完成
因为感觉 实在 没有必要 个人感觉ORM 使用与 团队中
的人 大多不熟悉复杂SQL的项目如果 团队里人都很
熟悉 SQL 个人看不出 ORM的好处
另外个人觉得 很多社区里 倡导ORM的有各 误区
总是 认为ORM 是主要实现持久化的
其实ORM 主要是 OO的方式 处理业务规则的
数据持久化 本就不是什么复杂的东西 用不用ORM
区别不大 就是不用ORM也一样能 提高开发效率 而且不一定
比用ORM 效率低我是说用DATASET，DATATABLE
可是 用ORM进行业务规则最大的考虑就是业务架构
可是 有多少 大项目的 架构师 真正能 设计出 合理的架构呢
本人 的能力 经过几次尝试 发现 确实不行
因为 对 业务规则OO需要定义很多 CLASS 多得让你
头皮发麻
后来 发现还是SQL搞定算了，毕竟大家都很多熟悉SQL
哈哈 本人 以前从事 商业零售 行业的软件 现在
作WMS 呵呵
欢迎大家一起讨论。
那怎么判断一个ORM是否复杂呢？
1.全部使用对象的方式来操作数据库。（按理说，所有的开发人员应该都是见不到物理表的，所见的只能是视图，函数，或存储过程）
2.由机器自动生成SQL并执行。（EF生成的SQL好么，你用一张C#的内存表关联一张数据库的一张表试试看，那长长的SQL，那淡淡的忧伤）
3.包含复杂的查询语法，企图用一套自己的语法来通吃所有数据库。（你明白的，通吃有用？学习啥语法都不如学好SQL，数据库就那几种，SQL都差不多的）
什么才是真正的面向对象程序设计？
领域驱动设计DDD
从分层角度来看，现在三层架构：表现层、业务层和持久层，三个层次应该分割明显，职责分明：持久层职责持久化保存业务模型对象，业务层对持久层的调用只是帮助我们激活曾经委托其保管的对象，所以，不能因为持久层是保管者，我们就以其为核心围绕其编程，除了要求其归还模型对象外，还要求其做其做复杂的业务组合。打个比喻：你在火车站将水果和盘子两个对象委托保管处保管，过了两天来取时，你还要求保管处将水果去皮切成块，放在盘子里，做成水果盘给你，合理吗？
现在使用Hibernate人也不少，但是他们发现Hibernate性能缓慢，所以寻求解决方案，其实并不是 Hibernate性能缓慢，而是我们使用方式发生错误：
“最近本人正搞一个项目，项目中我们用到了struts1.2+hibernate3,由于关系复杂表和表之间的关系很多，在很多地方把lazy都设置false，所以导致数据一加载很慢，而且查询一条数据更是非常的慢。”
Hibernate是一个基于对象模型持久化的技术，因此，关键是我们需要设计出高质量的对象模型，遵循DDD领域建模原则，减少降低关联，通过分层等有效办法处理关联。如果采取围绕数据表进行设计编程，加上表之间关系复杂（没有科学方法处理、侦察或减少这些关系），必然导致系统运行缓慢，其实同样问题也适用于当初对EJB的实体Bean的CMP抱怨上，实体Bean是Domain Model持久化，如果不首先设计Domain Model，而是设计数据表，和持久化工具设计目标背道而驰，能不出问题吗？关于这个问题N多年就在Jdon争论过。
这里同样延伸出另外一个问题：数据库设计问题，数据库是否需要在项目开始设计？
如果我们进行数据库设计，那么就产生了一系列问题：当我们使用Hibernate实现持久保存时，必须考虑事先设计好的数据库表结构以及他们的关系如何和业务对象实现映射，这实际上是非常难实现的，这也是很多人觉得使用ORM框架棘手根本原因所在。
当然，也有脑力相当发达的人可以实现，但是这种围绕数据库实现映射的结果必然扭曲业务对象，这类似于两个板块（数据表和业务对象）相撞，必然产生地震，地震的结果是两败俱伤，软的一方吃亏，业务对象是代码，相当于数据表结构，属于软的一方，最后导致业务对象变成数据传输对象DTO, DTO满天飞，性能和维护问题随之而来。
领域建模解决了上述众多不协调问题，特别是ORM痛苦使用问题，关于ORM/Hibernate使用还是那句老话：如果你不掌握领域建模方法，那么就不要用Hibernate，对于这个层次的你：也许No ORM 更是一个简单之道： No ORM: The simplest solution
现在回到我们讨论的重点上来，分层架构是我们使用Java的根本原因之一，域建模专家Eric Evans在他的“Domain Model Design”一书中开篇首先强调的是分层架构，整个DDD理论实际是告诉我们如何使用模型对象oo技术和分层架构来设计实现一个Java项目。
我们现在很多人知道Java项目基本有三层：表现层 业务层和持久层，当我们执著于讨论各层框架如何选择之时，实际上我们真正的项目开发工作还没有开始，就是我们选定了某种框架的组合（如Struts+Spring+Hibernate或Struts+EJB或Struts+JdonFramework），我们还没有意识到业务层工作还需要大量工作，DDD提供了在业务层中再划分新的层次思想，如领域层和服务层，甚至再细分为作业层、能力层、策略层等等。通过层次细化方式达到复杂软件的松耦合。DDD提供了如何细分层次的方式
当我们将精力花费在架构技术层面的讨论和研究上时，我们可能忘记以何种依据选择这些架构技术？选择标准是什么？领域驱动设计DDD 回答了这样的问题，DDD会告诉你如果一个框架不能协助你实现分层架构，那就抛弃它，同时，DDD也指出选择框架的考虑目的，使得你不会人云亦云，陷入复杂的技术细节迷雾中，迷失了架构选择的根本方向。
什么才是合适的方式？
因为面向过程的种种缺点，所以选择面向对象程序设计方法。
然而面向对象天生无法完全准确表示关系型数据，所以对于一些复杂的关系，使用orm就不一定合适了，比如当一个事务涉及到多个SQL语句时或者涉及到对多个表的操作时就要考虑用存储过程；当在一个事务的完成需要很复杂的商业逻辑时（比如，对多个数据的操作，对多个状态的判断更改等）要考虑；还有就是比较复杂的统计和汇总也要考虑，但是过多的使用存储过程会降低系统的移植性。
ORM应该是一个必备工具，但它不能代替原生的数据库操作，在复杂的查询需求下，sql或存储过程还是很有必要的。我觉得以ORM为主，辅之以sql或存储过程，是比较实用的策略，以往的存储过程一本被滥用了，将很多业务处理逻辑都封装的存储过程中，将压力完全集中到了数据库这一层。
上周我在在上讨论了ORM，在那以后有人希望我澄清我的意思。事实上，我曾经写文章讨论过ORM， 但那是在一场关于SQL的大讨论的上下文中，我不应该把这将两件事情混为一谈。因此，在本文中我将关注ORM本身。同时，我尽力保持简略，因为从我的SQL文章中显而易见的是：人们倾向于一旦读到让他们发怒的内容就会离开（同时留下一句留言，而不论他们所关注的东西是否在后面会讨论到）。
什么是反模式？
我很高兴地发现Wikipedia有一个相当全面的关于反模式的列表，包括来自编程界及其之外的内容。我之所以称ORM为反模式的原因是因为，反模式的作者定义了用来区分反模式和普通的坏习惯的两个条件，而ORM完全符合这些条件:
1. 它开始的时候看起来很有用，但是从长期来看，坏处要大过好处
2. 存在已验证并且可重复的替代方案
由于第一个因素导致了ORM令人抓狂（对我来说）的流行性：它第一眼看上去像是个好主意，但是当问题更加明显的时候，已经很难离开了。
这对ORM来说是什么意思？
我想说的主要问题在于 ActiveRecord，它由于 Ruby on Rails 而著名，从那以后已经移植到了许多其他语言。然而，这些问题同样存在于其他的ORM层，比如Java的Hibernate和PHP的Doctrine。
ORM的优点
- 简单：一些ORM层告诉你它们“消除了对SQL的要求”。我至今仍然看到这种承诺在传播。其他一些会更加现实地声称它们可以减少手写SQL的需要，但是仍然允许你在需要的时候使用它。对于简单的模型以及项目的早期，这确实是一个优点：使用ORM，无疑你能够更快地开始启动。然而，你将会走向错误的方向。
- 代码生成：使用ORM从模型中消除用户层面的代码，这一做法开启了通向代码生成的大门。通过对schema的简单描述，“脚手架”模式可以为你的所有表生成一个可工作的界面。更加具有魔力的是，你可以修改你的schema描述，然后重新生成代码，从而消除了CRUD。同样，这在开始的时候确实是可行的。
- 性能“足够好”：我没有看到任何ORM层声称在性能上更加优越。很明显，为了代码的敏捷性需要付出性能的代码。如果哪里变慢了，你总是可以用更加有效的手写SQL覆盖你的ORM方法。不是吗？
ORM的问题
1. 不充分的抽象
ORM最明显的问题是它并不能完全从实现细节中抽象出来。所有主流ORM的文档中到处都引用了SQL的概念。其中一些介绍的时候并不会表明其在SQL中的等价物，而其他一些则将库看作用来生成SQL的过程函数。
抽象的要点在于它应该使问题得以简化。对SQL进行抽象，同时又要求你懂得SQL，这使得你需要学习的东西成倍增加了：首先，你必须理解你正在试图执行的SQL是什么，然后你还要学习ORM的API，来让它为你编写这些SQL。在Hibernate中，为了完成复杂的SQL你甚至需要学第三种语言：HQL，它几乎就是SQL（但又不完全是），其在幕后被翻译成SQL。
ORM的支持者会辩解说并非每个项目都是如此，并非每个人都需要复杂的join，并且ORM是一个"80/20"解决方案，其中80%的用户只需要SQL中20%的功能，ORM可以处理这些问题。我能说的是，我15年来编写web应用的数据库后端的经历表明，事实并非如此。只有在项目刚开始的时候你不需要join和本地join。在那之后，你就要优化和巩固你的查询。即使80%的用户只用到SQL中30%的功能，可是100%的用户都需要打破ORM的抽象才能够完成工作。
2. 不正确的抽象
如果你的项目确实不需要任何关系数据功能，那么ORM可以非常完美地为你工作。但是接下来你又遇到另外一个问题：你用错了了数据存储。关系存储的额外付出是非常高的；这就是为什么NoSQL数据要快得多的重要原因之一。然而，如果你的数据是关系型的，那么额外的付出就是值得的：你的数据库不仅存储数据，它还表达了你的数据，并且可以基于关系概念回答关于它的问题，这比你用过程代码能够做到的要快速得多。
但是，如果你的数据不是关系型的，那么你就是在不适当的场合使用SQL，这为你增加了巨大且不必要的负担；为了让问题更加严重，你在其上又增加了一重额外的抽象。
另一方面，如果你的数据是关系型的，那么你的对象映射最终会失败。SQL是关于关系代数的：SQL的输出不是对象，而是对于某个问题的解答。如果你的对象“是一个”X的实例，并且“拥有一些”Y，且每个Y“属于”Z，那么对象在内存中正确的表达形式是什么？它应该是X的属性，或者全部包含在Y中，或者/并且全部包含在Z中？如果你只得到X的属性，那么何时你运行查询来获得Y呢？而且，你是想要其中一个还是全部？现实中，答案是依赖于条件的：这就是为什么我说SQL是对于问题的回答。对象在内存中的表达形式取决于你的意图，然而面向对象设计没有依赖于上下文的表达这样的功能。关系不是对象；对象也不是关系。
3. 多个查询导致失败
这自然的引出了ORM的另一个问题：效率低下。当你获取一个时，你需要哪些属性？ORM并不知道，所以它总是取得全部（或者它要求你告诉它，但是这又打破了抽象）。开始的时候这不成问题，但是当你一次取出上千条纪录的时候，如果你只需要3个属性却不得不取出全部30列，这时就产生了严重的性能问题。许多ORM层非常不善于推断join，从而不得不使用分离的查询来获取关联数据。如前所述，许多ORM层明确声明效率将会有所牺牲，其中一些提供了某些机制来调整引起问题的查询。我从过去的经历中发现的问题表明，很少有只需要调整单个“银弹”查询的情况：应用的数据库后端之所以死掉不是因为其中某一条查询，而是众多的查询引起的。ORM缺少上下文敏感的性质意味着它无法巩固查询，相反必须借助cache或其他机制来进行一定程度的补偿。
那么替代方案是什么?
希望到这里我已经澄清ORM在设计上的一些缺陷。但是要作为一个反模式，还需要存在替代的解决办法。事实上有两个取代方法：
1. 使用对象
如果你的数据是对象，那么停止使用关系数据库。编程界当前正在出现键-值对存储的浪潮，它允许你以闪电般的速度访问优雅的、自我包含的海量数据。没有法律规定编写Web应用的第一步必须安装MySQL。对于对象的每一种表达方式都使用关系数据库是一种过度使用，这也是近几年SQL的名称不太好的原因之一。事实上，问题在于偷懒的设计。
2. 在模型中使用SQL
编程中作任何事情都只有一种正确的方式，这是一种危险的说法。然而根据我的实践，在面向对象的代码中表达关系模型的最佳方法仍然是模型层：将你的所有数据表示封装在一个单独的区域是一个好注意。然而，记住模型层的工作簿在于表达对象，而在于回答问题。提供一个可以回答你的应用程序所包含的问题的API，尽量保持简洁高效。有时候，这些回答显得格格不入，以致于看上去是“错误的”，甚至对于资深的OO开发者也是如此。但是，你可以根据经验来更好地找到其中的普遍性，从而允许你将多个查询方法重构为单个。
类似的，有时候输出会是单个对象X，它很容易表达。但是也有时候输出是聚合的对象表格，或者单个整数值。你要忍住将这些内容用过多抽象来包装的诱惑，用对象自身的术语来描述。首要的是，不要相信OO能够表达任何对象和所有对象。OO本身是一种优美和灵活的抽象，但关系数据在其范围之外，把它不能表达的东西伪装成对象是ORM的核心与真正的问题。
总结
- ORM最初比编写基于SQL的模型代码更快，也更容易理解
- 它在任何项目早期都是足够有效的
- 不幸的是，这些优点在项目复杂性提升的时候就消失了：抽象被打破，开发者被迫使用并理解SQL
- 完全是非正式的声明，我认为ORM对抽象的破坏不是仅仅涉及20%的项目，而是几乎100%。
- 对象并不足以充分表达关系查询的结果。
- 关系查询映射到对象的不充分性导致了ORM后端应用的效率低下，这些问题普遍分布在应用的各处，并且除了完全放弃ORM之外，没有简单的解决办法。
- 不要对任何问题都使用关系存储与ORM，而是更加仔细地思考你的设计
- 如果你的数据天生就是对象，那么请使用对象存储（"NoSQL"）。它们要比关系数据库快得多。
- 如果你的数据天生就是关系型的，那么关系数据库带来的开销是值得的。
- 把你的关系查询封装在模型层中，设计你的API从而为应用提供数据访问支持；拒绝过分泛化的诱惑。
- 面向对象无法以有效的形式表达关系数据；这是面向对象设计的一个基本限制，ORM无法修复它。