我要遵守11文章数据库设计指南
前言：笔者Shivprasad koirala，前微软ASP/ASP.NET的MVCproject联赛。现在，他在印度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来计算，这就是数据冗余的表现之中的一个。所以碰到这样的派生于其它列的字段，要好好想一想，这个字段真的须要吗？
这条准则正如第三范式所说：字段不能依赖于不论什么非主键字段。我个人觉得不要盲目遵循第三范式，要视情况而定。存在冗余的数据并不总是坏事。假设这些冗余数据是通过计算得来的，看情况来决定要不要遵守第三范式。
准则8：假设性能才是关键，那就不要很严格地避免冗余数据
不要把"避免一切冗余数据"当成一条死命令。假设对性能的要求非常高，就考虑一下非标准化吧。遵守标准的话。你常常须要使用join命令来连接非常多个表格，但在非标准化中，通过设置一些冗余信息。就没那么多join命令了。所以性能会好得多。
准则9：多维度的数据是一种全然不同的野兽
使用OLAP（分析型）数据库的项目主要处理的是多维数据。举例来说的话你能够看一下下图，你想要得到每一个国家的销量，每一个顾客的销量和其它数据。简单来说，你所关注的销量是三个维度数据的交集。
这样的情况下，设计成一个维度将会更好。简单来说。你能够建立一个拥有"sales amount"字段的销量表（它为中心表），然后设置一些外键来和其它的一维表相关联。
准则10：集中化键值表的设计
我常常会碰到键值表。
键值表的意思是，它存储着键和和与这个键相相应的数据（译者注：就像数据结构中的map的使用方法一样，是一种结构相当简单的表）。举例来说，下表你能够看到有一个Currency 表和Country表。细致观察就会发现，实际上这两张表中仅仅有一个键和一个相应值而已。
对于这样的类型的数据表，创建一个集中化的表然后设立一个"Type"字段来区分。
这会使你的数据库工作的更好。
准则11：对于多级数据要引用自身的主键。或是设立外键
我也会常常会碰到多集数据的情况。考虑一个多级的销售方案，一个销售员旗下能够有非常多个销售员。在这样的情况下，引用自身的主键或是设立外键都会帮助你达到想要的效果。
这篇文章并非让你不要遵守标准范式。而是让你不要盲目遵守，你要首先考虑的是项目的属性和你要处理什么类型的数据。
以下是一个用简单的学校表来手把手解释三个标准范式的视频（译者注：与上文中的“3 normal forms”为同一个视频，下载过的读者可不必反复下载）
SQL Server -- Can you explain First,Second and Third normal form in SQL server [part1]
SQL Server -- Can you explain First,Second and Third normal form in SQL server [part2]
SQL Server -- Can you explain First,Second and Third normal form in SQL server [part3]
（掌声）
从原来的：http://www.codeproject.com/Articles/359654/11-important-database-designing-rules-which-I-foll
