前言：作者Shivprasad koirala，前微软ASP/ASP.NET的MVC工程师，现于印度任CEO职位。学生初次翻译，如有不妥，不吝赐教。

简介

在你开始阅读这篇文章之前，我要先告诉你我不算是数据库设计方面的什么大师。下面的11条准则，是我从项目、从我自身的经验和我自己的理解和学习中得来的。我个人认为在数据库设计方面运用这些准则能使我受益匪浅。我也欢迎任何批评与指点。

我之所以要写这么一篇详尽的文章，是因为，许多开发者设计数据库的时候十分信奉“三个范式”（译者注：而没有结合实际情况）。他们认为三范式是数据库设计的唯一真谛。随着项目开发的不断推进，持有这些想法的人会经常碰壁和遇上无穷无尽的麻烦。

如果你还不太了解什么是范式，可以点击这里：3 normal forms: part1-part2-part3(译者注：原文为yotube视频，由于众所周知的原因国内无法观看，我已将原视频分享到csdn下载区，下载免积分)，这个教程将会手把手教你这三个范式。

准则1：应用的本质是什么（OLTP还是OLAP）？

（译者注：联机事务处理或联机分析处理，即偏向于增删改查还是偏向于数据分析）

当你开始设计数据库的时候，所要做的第一件事是分析你设计的应用的本质，是事务型呢还是分析型呢。你会发现，许许多多的开发者根本没有考虑自己的应用到底是属于哪种类型，而是全部按照“范式”的准则来设计，然后就碰上了各种各样的性能和定制的问题。正如我所说，有两种应用：基于事务型的和基于分析型的，那么接下来让我们了解一下这两种类型具体是什么。

事务型：这种类型的应用，最终用户对增删改查更为关注，比如，增加、读取、更新和删除记录。对于这种类型的数据库，正式来说我们称呼为OLTP(译者注：Online Transaction Processing，联机事务处理)。

分析型：这种类型的应用，最终用户更关注与对数据的分析、产生报告和对数据的预测等。这种类型的数据库很少执行插入或是更新数据的操作。这种设计的主要意图是以最快的速度从数据库获取数据，并进行分析。对于这种类型的数据库，正式来说我们称呼为OLAP（译者注：Online Analytical Processing，联机分析处理）。

换句话说，如果你发现在数据库上进行插入、更新或删除更为重要，那你应该遵循标准的范式来设计，否则应该建立一个扁平非规范的数据库结构。

下图展示了如何在左侧姓名和地址表中运用非规范化设计思想，来创建右侧的不遵守标准范式的扁平的非规范数据结构。

准则2：将你的数据划分成若干逻辑片段，让生活更美好

这条准则实际上就是第一范式。违背了这条准则的一个明显特征是，你的查询语句中用了一大堆字符串解析函数，如substring、charindex等。如果的却是这样，那么你需要应用一下这条准则。

举个例子，下图表中有个字段是“Student Name”，如果你想要查询名字中带有"Koirala"而不带有"Harisingh"的学生，你可以想象到时候你写出来的查询语句是什么样的。

所以一个更好的方案是将这个字段分解成更详细的逻辑片段，这样我们就能写出更干净，也更完美的查询语句了。

准则3：不要过度使用准则2

开发人员们都是聪明人。如果你告诉了他们一个门路，那么他们就总是使用这个方法。准则2用过头会导致一些你根本不想要的结果。但是准则2本身是非常有用的。当你想着"把这玩意儿拆了"的时候，暂停一下，问问你自己，真有必要拆吗？正如我刚才所说，拆分必须是逻辑性的。

举个例子，你可以看到下图中有个电话号码的字段，你几乎不会对号码的ISD（International Subscriber Dialing，国际订户拨号）分别进行管理（除非哪个项目里真有这个需求），所以就这么把号码放着显然更明智。要是你真的把它们拆了，那到时候你就得面对一大堆的"拆分后遗症"了。

准则4：冗余的不统一数据是你最大的敌人

小心冗余数据，并重构它们。我并不担心冗余数据会占用很多磁盘空间，我所担心的是这些冗余数据所造成的困惑与混乱。

比如说，在下图中，你会发现“5th Standard”和“Fifth standard”是一个意思，只不过描述的形式略微不同。你可能会解释说，这些数据是之前有人乱录入的，而且还没有经过验证。当你打算导出一个报告的时候，对于这个字段将产生两份不一样的报告，当用户看到这样的报告，他们恐怕就要在风中凌乱了。

一个解决办法就是，把这些数据移到一个新表中，然后原来的表以引用的方式使用这些数据。下图中你可以看到，我创建了一个新的叫做"Standards"的表，然后用一个外键将这两个表连接起来。

准则5：小心那些用分隔符分开的数据

第一范式的第二条内容规定了一个位置上不能存多个值。下图就是一个存了多个值的例子。仔细观察"Syllabus"字段就会发现，我们塞了太多的数据到这个字段中了。这种字段我们成为"重复组"，如果我们要操作这些数据，不仅查询语句会写的很复杂（且不论对错），而且我很怀疑这种查询的效率。

这种某些列里塞了很多数据的字段，要特别小心的对待，一个比较好的解决办法是：将这些字段移到不同的表中，然后将它们用外键相连，以便于从逻辑和操作上更好的进行管理。

我们需要遵守第一范式的第二条规定：一个位置不能存储多个值。从上图中可以看到，我建立了一个独立的"syllabus"表，然后与主表建立了多对多的关联。

用这种方法的话，主表中的"syllabus"字段不再塞入一大堆用分隔符分开的数据了。逻辑上易于理解，操作性也更强。

准则6：小心部分依赖

小心那些部分依赖于主键的字段，例如上图中的主键是Roll Number和Standard。现在来看看“syllabus”，这个字段与standard字段相关联，而不直接与Student（“Roll Number”字段）相关联。

“syllabus”字段与学生正在学习的"standard"字段相关联，而没有直接和学生关联。那么明天我想要更新“syllabus”的时候，我就必须把所有与之相关的"Student"字段也更新掉。老兄，这是个辛苦的体力活，而且还毫无逻辑！所以更有意义的做法是将"syllabus"字段单独拉出来然后与"Standard"通过外键关联。

你可以看到我是如何将"syllabus"字段拉出来然后与“Standards”相联系。

这条准则其实就是第二范式本身：所有的属性必须做到全部依赖，不应该有字段是部分依赖主键的。

准则7：仔细地选择派生列

如果你设计的是OLTP型数据库，即事务型数据库，避免派生列将会是很明智的，除非对这一块内容的性能有高要求。但是对于需要大量求和与计算的OLAP数据库，即分析型数据库，这些派生列就显得很有必要而且能使数据库性能更加优越。

上图中你可以看到，Average依赖Total Marks和Total Subject来计算，这就是数据冗余的表现之一。所以碰到这种派生于其他列的字段，要好好想一想，这个字段真的需要吗？