11种重要的数据库设计规则-lixh

十一种重要的数据库设计规则

2012年4月4日作者：Shivprasad

2010年4月15日译者：lixh

十一种重要的数据库设计规则 (1)

简介 (2)

规则1：应用的本质（OLTP或OLAP）？ (2)

规则2：数据进行逻辑分块，使你的生活更简单 (3)

规则3：不要过多的使用规则2 (4)

规则4：重复、无规则的数据将是你最大的敌人 (4)

规则5：注意分离器的数据分离 (5)

规则6：注意数据依赖 (7)

规则7：重视派生列的选择 (8)

规则8：如果注重性能，不要避开冗余数据 (8)

规则9：多维数据区分于复杂数据 (9)

规则10：名称-值表的设计 (10)

规则11：无限制的自我参数等级数据PK和FK。 (11)

译者话：

我在网上无意中看到这篇文章，是中文版的，出自CSDN，当时我想收藏，但版主声明了转发需要他本人同意，所以我决定重新翻译此英文原文。这篇文章写的真不错，可以好好的揣摩一下作者的深意，唯一让我感觉到不舒服的地方是作者太过方言化了，以至于部分句子我家的专业翻译也没弄明白。由于本人能力有限，此文章只做参考，建立您阅读原文。

英文原文地址：

/UploadFile/shivprasadk/11-important-database-designing-rules/# Introduction

--------------------------------------------------------------------------------------------------------------------------------- 这篇文章将描述11种重要的数据库设计规则。

简介

在读这篇文章之前，让我确认一下，我不是数据设计方面的大师，如下所示的十一点是我经过学习项目所获得到的经验。我个人认为，在数据库设计过程中对我来说帮助很大。欢迎任何批评。

我写这个完整的文章原因是，当开发者座下来设计一个数据库时，他们趋向于三种常规模式（“like a silver bullet.”没翻译成功，不知道是什么意思，应该是根深蒂固的意思吧）。他们常常认为常规化设计是唯一的途径。由于这种心态，修改问题（原文“hit road blocks”）作为项目推进的方法。

如果你是一个新的常规化设计，则点击观看“3种常规模式”，这里详细介绍了所有三种常规模式。

我们所说、所做的标准化规则，是非常重要的准则，（“but taking them as a mark on stone is calling for troubles.”没翻译好）但是在使用它们存在着顽固的调用麻烦。接下来是我自己理解的11条规则，记得在前面提到，这11条规则用于数据库设计。

规则1：应用的本质（OL TP或OLAP）？

当你开始你的数据库设计时，第一件事是分析你设计的应用本质是什么，是事务型还是分析型，你会发现许多开发者默认使用常规化的规则，而不考虑应用的本质，最后考虑性能与定制问题。说到这里，是基于事务性和基于分析性两种方法，让我们来理解这两种方法：Transactional（事务型）：在这类应用中，用户最感兴趣的是CRUD（Create、Retrieve、Update、Delete），即创建、查询、更新和删除记录。这类数据库的正式命名为OLTP（On-Line Transaction Processing在线事务处理）。

Analytical（分析型）：在这类应用中，用户最感兴趣的是分析、报告、预测等。这类数

据库很少用到插入与更新操作。这里主要的目的是尽可能快速的获取和分析数据。这类数据库正式命名为OLAP（On-Line Analytical Processing在线分析处理）。

换句话说，如果你认为插入、更新或删除更重要，则使用常规化的表单设计或者建立一个简单的非常规化的数据结构。

下面是一个简单的图表，左边的表显示了名称（Name）和地址（Address），是应用非规范化结构创建出来的一个简单地常规化表单。

规则2：数据进行逻辑分块，使你的生活更简单

这个规则实际上是从第一范式演变过来的第一种规则。违反这种规则的第一种模式是，如果你查询使用了太多字符串解析功能，像子串、字符索引等，可能需要应用此规则。

例如，如下表所示，其中有学生的名字（Student Name），如果你想查询学生的名字包含“Koirala”而没有“Harisingh”，你可以想像使用什么方法可以实现。

所以更好的方法是打破这一字段，进行更多的逻辑分块，所以我们能写出最简洁、高效的查询方法。

规则3：不要过多的使用规则2

开发者们思维很单一，如果你告诉他这个方法，他们会一直这样做下去，过度使用它，会导致不必要的后果。这也适用于刚刚谈到的规则2。当你考虑分解时，你会停顿一下，问自己是否需要这样做，分解必须具有一定逻辑性。

例如，你可以看到电话号码字段（Phone Number），你将操作ISD（international subscriber dialing 国际电话加入者拨号通话）代码，将电话号码段分离（直到满足你的需求），因此，这将是明智的选择，当然，分离它可能会导致更多的并发症。

规则4：重复、无规则的数据将是你最大的敌人

聚焦、重构重复的数据。我个人担心的不是关于重复数据它占用空间，而是它造成混乱。

例如，在接下来的图表中，你能看到“5th Standard”和“Fifth standard”含义相同。现在，你可以说因为录入了坏数据或者数据验证错误是系统原因。现在如果你想获得一份报表，它们可能显示为不同的实体，从最终用户角度来看，是非常困难的。