在日常的数据库开发过程中，很多开发者一参与到数据库设计，就会很自然地把 “三范式” 当作自己的信条。他们往往认为遵循这个规范就是数据库设计的唯一标准。由于这种心态，他们往往尽管一路碰壁也会坚持把项目做下去。

对于这种现象，中培教育《 Oracle数据库管理与性能调优实践》培训专家袁老师指出，一些规范当然很重要，但是不需要死记硬背，只要掌握一些规则即可。袁老师在这里分享了11个在数据库设计过程中应该遵守的规则。

规则 1：弄清楚将要开发的应用程序是什么性质的（OLTP 还是 OPAP）？

当你要开始设计一个数据库的时候，你应该首先要分析出你为之设计的应用程序是什么类型的，它是 “事务处理型”（Transactional） 的还是 “分析型” （Analytical）的？你会发现许多开发人员采用标准化做法去设计数据库，而不考虑目标程序是什么类型的，这样做出来的程序很快就会陷入性能、客户定制化的问题当中。正如前面所说的，这里有两种应用程序类型， “基于事务处理” 和 “基于分析”

规则 2：将你的数据按照逻辑意义分成不同的块，让事情做起来更简单

这个规则其实就是 “三范式” 中的第一范式。违反这条规则的一个标志就是，你的查询使用了很多字符串解析函数

规则 3：不要过度使用 “规则 2”

开发者都是一群很可爱的生物。如果你告诉他们这是一条解决问题的正路，他们就会一直这么做下去，做到过了头导致了一些不必要的后果。这也可以应用于我们刚刚在前面提到的规则2。当你考虑字段分解时，先暂停一下，并且问问你自己是否真的需要这么做。正如所说的，分解应该是要符合逻辑的。

规则 4：把重复、不统一的数据当成你最大的敌人来对待

集中那些重复的数据然后重构它们。我个人更加担心的是这些重复数据带来的混乱而不是它们占用了多少磁盘空间。

规则 5：当心被分隔符分割的数据，它们违反了“字段不可再分”

前面的规则 2 即“第一范式”说的是避免 “重复组” 。这些被塞满了分隔符的数据列需要特别注意，并且一个较好的办法是将这些字段移到另外一个表中，使用外键连接过去，同样地以便于更好的管理。

规则 6：当心那些仅仅部分依赖主键的列

留心注意那些仅仅部分依赖主键的列。你可以看到我们是如何移动 syllabus（课程）字段并且同样地附上 Standard 表。这条规则只不过是 “三范式” 里的 “第二范式”：“所有字段都必须完整地依赖主键而不是部分依赖”。

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

如果你正在开发一个 OLTP 型的应用程序，那强制不去使用派生字段会是一个很好的思路，除非有迫切的性能要求，比如经常需要求和、计算的 OLAP 程序，为了性能，这些派生字段就有必要存在了。

规则 8：如果性能是关键，不要固执地去避免冗余

不要把 “避免冗余” 当作是一条绝对的规则去遵循。如果对性能有迫切的需求，考虑一下打破常规。常规情况下你需要做多个表的连接操作，而在非常规的情况下这样的多表连接是会大大地降低性能的。

规则 9：多维数据是各种不同数据的聚合

OLAP 项目主要是解决多维数据问题。比如你可以看看下面这个图表，你会想拿到每个国家、每个顾客、每段时期的销售额情况。简单的说你正在看的销售额数据包含了三个维度的交叉。

为这种情况做一个实际的设计是一个更好的办法。简单的说，你可以创建一个简单的主要销售表，它包含了销售额字段，通过外键将其他所有不同维度的表连接起来。

规则 10：将那些具有“名值表”特点的表统一起来设计

这种 “名值表”往往比较常见  “名值表” 意味着它有一些键，这些键被其他数据关联着。

规则 11：无限分级结构的数据，引用自己的主键作为外键

我们会经常碰到一些无限父子分级结构的数据（树形结构？）。例如考虑一个多级销售方案的情况，一个销售人员之下可以有多个销售人员。注意到都是 “销售人员” 。也就是说数据本身都是一种。但是层级不同。这时候我们可以引用自己的主键作为外键来表达这种层级关系，从而达成目的。