◆ 简介

　　在您开始阅读这篇文章之前，我得明确地告诉您，我并不是一个数据库设计领域的大师。以下列出的 11 点是我对自己在平时项目实践和阅读中学习到的经验总结出来的个人见解。我个人认为它们对我的数据库设计提供了很大的帮助。实属一家之言，欢迎拍砖 ： ）

　　我之所以写下这篇这么完整的文章是因为，很多开发者一参与到数据库设计，就会很自然地把 “三范式” 当作银弹一样来使用。他们往往认为遵循这个规范就是数据库设计的唯一标准。由于这种心态，他们往往尽管一路碰壁也会坚持把项目做下去。

　　大家都说标准规范是重要的指导方针并且也这么做着，但是把它当作石头上的一块标记来记着（死记硬背）还是会带来麻烦的。以下 11 点是我在数据库设计时最优先考虑的规则。

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

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

　　事务处理型：这种类型的应用程序，你的最终用户更关注数据的增查改删（CRUD，Creating/Reading/Updating/Deleting）。这种类型更加官方的叫法是 “OLTP” 。

　　分析型：这种类型的应用程序，你的最终用户更关注数据分析、报表、趋势预测等等功能。这一类的数据库的 “插入” 和 “更新” 操作相对来说是比较少的。它们主要的目的是更加快速地查询、分析数据。这种类型更加官方的叫法是 “OLAP” 。

　　那么换句话说，如果你认为插入、更新、删除数据这些操作在你的程序中更为突出的话，那就设计一个规范化的表否则的话就去创建一个扁平的、不规范化的数据库结构。

　　以下这个简单的图表显示了像左边 Names 和 Address 这样的简单规范化的表，怎么通过应用不规范化结构来创建一个扁平的表结构。

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

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

　　例如 substring、charindex 等等。若真如此，那就需要应用这条规则了。

　　比如你看到的下面图片上有一个有学生名字的表，如果你想要查询学生名字中包含“Koirala”，但不包含“Harisingh”的记录，你可以想象一下你将会得到什么样的结果。

　　所以更好的做法是将这个字段拆分为更深层次的逻辑分块，以便我们的表数据写起来更干净，以及优化查询。