问答一下,轻松解决,电脑应用解决专家!
主板显卡CPU内存显示器
硬盘维修显卡维修显示器维修
注册表系统命令DOS命令Win8
存储光存储鼠标键盘
内存维修打印机维修
WinXPWin7Win10/Win11
硬件综合机箱电源散热器手机数码
主板维修CPU维修键盘鼠标维修
Word教程Excel教程PowerPointWPS
网络工具系统工具图像工具
数据库javascriptLinux系统
PHP教程CSS教程XML教程

11条重要的数据库设计原则

更新时间:2012-04-16 19:56 作者:佚名点击:

    在你开始阅读这篇文章之前,我(指原文作者)得明确地告诉你,我并不是一个数据库设计领域的大师。以下列出的11点是我从自己在平时项目实践和阅读中学习到的经验总结出来的个人见解。我个人认为它们对我的数据库设计提供了很大的帮助。

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

    如果你对 “三范式” 不清楚,请点击这里一步一步的了解什么是“三范式”。

    大家都说标准规范是重要的指导方针,并且也都这么做,但是死记硬背还是会带来麻烦的。以下11点是我在数据库设计时会优先考虑的规则。

    规则1:弄清楚将要开发的应用程序是什么性质的(OLTP 还是 OLAP)?

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

    事务处理型:对于这种类型的应用程序,你的用户更关注数据的增查改删(CRUD,Creating/Reading/Updating/Deleting)。这种类型官方称之为 “OLTP”。

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

 

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

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

 

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

    这个规则其实就是 “三范式”中的第一范式。违反这条规则的一个标志就是:你的查询使用了很多字符串解析函数,例如 substring、charindex 等等。若真如此,那就需要应用这条规则了。

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

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

 

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

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

    例如,你可以看到电话号码这个字段,你很少会把电话号码的 ISD 代码单独分开来操作(除非你的应用程序要求这么做)。所以一个很明智的决定就是让它保持原样,否则这会带来更多的问题。

 

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

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

    例如下面这个图表,你可以看到 "5th Standard" 和 "Fifth standard" 是一样的意思,它们是重复数据。现在你可能会说是由于那些录入者录入了这些重复的数据或者是差劲的验证程序没有拦住,让这些重复的数据进入到了你的系统。 现在,如果你想导出一份将原本在用户眼里十分困惑的数据显示为不同实体数据的报告,该怎么做呢?

 

    解决方法之一是将这些数据完整地移到另外一个主表,然后通过外键引用过来。在下面这个图表中你可以看到我们是如何创建一个名为Standards 的主表,然后同样地使用简单的外键连接过去。

 

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

    前面的规则 2 即“第一范式”说的是避免“重复组”。下面这个图表作为其中的一个例子解释了“重复组”是什么样子的。如果你仔细的观察 Syllabus 这个字段,会发现在这一个字段里实在是填充了太多的数据了。像这些字段就被称为“重复组”了。如果我们又得必须使用这些数据,那么这些查询将会十分复杂并且我也怀疑这些查询会有性能问题。

 

    这些被塞满了分隔符的数据列需要特别注意。一个较好的办法是将这些字段移到另外一个表中,使用外键连接过去,以便于更好的管理。

 

    那么,让我们现在就应用规则2(第一范式)“避免重复组” 吧。你可以看到上面这个图表,我创建了一个单独的 Syllabus表,然后使用“多对多” 关系将它与 Subject表关联起来。

    通过这个方法,主表(Student 表)的 Syllabus字段就不再有重复数据和分隔符了。

顶一下
(3)
75%
踩一下
(1)
25%
------分隔线----------------------------
你可能感兴趣的内容