网站内容设计基本原则(11ImportantDatabase设计领域的大师-11 )

　　网站内容设计基本原则(11ImportantDatabase设计领域的大师-11

)

　　英文原版：11条重要的数据库设计规则

　　介绍

　　在开始阅读此文章 之前，我必须明确说明我不是数据库设计大师。下面列出的 11 点是我通过平时的项目实践和阅读所学到的个人见解。我个人认为他们对我的数据库设计帮助很大。这是一家人的话，欢迎做砖:)

　　之所以写出这么完整的文章，是因为很多开发者一旦涉及到数据库设计，自然就会把“三范式”当成灵丹妙药。他们倾向于认为遵循这个规范是数据库设计的唯一标准。由于这种心态，他们经常不顾一路碰壁而坚持项目。

　　如果您对“三范式”不清楚，请点击这里（FQ）一步一步了解什么是“三范式”。

　　每个人都说规范是一个重要的指导方针，并且确实如此，但是将其作为岩石上的标记（死记硬背）来记住可能会很麻烦。以下 11 点是我在数据库设计中的首要任务。

　　规则 1：找出将要开发的应用程序（OLTP 或 OPAP）的性质是什么？

　　当您开始设计数据库时，您应该首先分析您正在设计的应用程序类型，是“事务性”还是“分析性”？您会发现许多开发人员采用标准化的方法来设计数据库，而不管目标程序的类型如何，并且生成的程序很快就会遇到性能和定制问题。前面说过，应用有两种类型，“基于事务”和“基于分析”，我们来看看这两种类型究竟是什么意思。

　　事务性：在这种类型的应用程序中，您的最终用户更关心添加、检查、修改和删除数据（CRUD，创建/读取/更新/删除）。这种类型的更正式名称是“OLTP”。

　　分析：在这种类型的应用程序中，您的最终用户更关注数据分析、报告、趋势预测等。这种类型的数据库“插入”和“更新”操作相对较少。它们的主要目的是更快地查询和分析数据。这种类型更正式的名称是“OLAP”。

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

　　下面的简单图表显示了如何使用简单的规范化表（如左侧的名称和地址）通过应用非规范化结构来创建平面表结构。

　　规则 2：将数据划分为逻辑块以使事情变得更容易

　　这个规则实际上是“三个范式”的第一个范式。违反此规则的一个迹象是您的查询使用了大量的字符串解析函数

　　例如 substring、charindex 等。如果是，则需要应用此规则。

　　例如，您看到的下图有一个收录学生姓名的表格。如果要查询学生姓名中收录“Koirala”但不收录“Harisingh”的记录，可以想象得到什么样的结果。.

　　所以更好的做法是把这个字段拆分成更深的逻辑块，这样我们的表数据可以写得更干净，也可以优化查询。

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

　　开发人员是一群可爱的生物。如果你告诉他们这是解决问题的正确方法，他们会继续这样做，并且会走得太远，带来不必要的后果。这也可以应用于我们之前提到的规则 2。当您考虑字段分解时，请暂停片刻，问问自己是否真的需要。如上所述，分解应该是合乎逻辑的。

　　例如，您可以看到电话号码字段，并且您很少会单独对电话号码的 ISD 代码进行操作（除非您的应用程序需要它）。所以一个非常明智的决定是让它保持原样，否则会导致更多的问题。

　　规则 4：将重复、不一致的数据视为最大的敌人

　　集中这些重复数据并重建它们。就我个人而言，我更关心这些重复项的混乱程度，而不是它们占用的磁盘空间。

　　例如在下面的图表中，您可以看到“5th Standard”和“Fifth Standard”的含义相同，它们是重复数据。现在你可能会说这是因为参赛者输入了重复数据或者糟糕的验证程序没有阻止它，让重复数据进入你的系统。现在，如果您想要导出一个报告，该报告显示的数据可能会令用户感到困惑，因为它是不同实体的数据？

　　一种解决方案是将数据完全移动到另一个主表并通过外键引用它。在下图中，您可以看到我们如何创建一个名为“Standards”（课程级别）的主表，并使用一个简单的外键再次加入它。

　　规则 5：当心由分隔符分隔的数据，它们违反“字段不可分离”

　　之前的规则 2，“第一范式”，说要避免“重复组”。下面的图表作为“重复组”的示例。如果您仔细查看教学大纲（课程）字段，您会发现该字段填充了太多数据。像这样的字段被称为“重复组”。如果我们不得不再次使用数据，查询将非常复杂，我怀疑这些查询会出现性能问题。

　　这些填充了分隔符的数据列需要特别注意，更好的方法是将这些字段移动到另一个表并用外键连接它们，再次进行更好的管理。

　　所以，让我们现在应用规则 2（第一范式）“避免重复组”。正如您在上图中所见，我创建了一个单独的教学大纲表，然后使用“多对多”关系将其与主题表相关联。

　　使用这种方法，主表（学生表）的教学大纲（课程）字段不再有重复数据和分隔符。

　　规则 6：注意仅部分依赖主键的列

　　注意仅部分依赖主键的列。比如上图中，我们可以看到这张表的主键是Roll No.+Standard。现在，如果您仔细查看 syllabus 字段，您会发现 syllabus (course) 字段仅关联（依赖于）Standard（课程级别）字段，而不直接关联（依赖于）学生（Roll No.场地）。

　　教学大纲（课程）字段与学生正在学习的课程级别（标准字段）相关，而不是直接与学生本身相关。那么如果我们明天要更新教学大纲（课程），我们就得为每个学生痛苦地修改它，这显然是不合逻辑的（一种不正常的做法）。将字段从该表移动到另一个表，然后将它们与标准（课程级别）表关联起来更有意义。

　　您可以看到我们如何移动教学大纲（课程）字段并附加标准表。

　　这条规则无非就是“三种范式”中的“第二范式”：“所有字段必须完全依赖主键而不是部分依赖”。

　　规则 7：谨慎选择派生列

　　如果你正在开发一个OLTP类型的应用程序，最好强制不要使用派生字段，除非有紧急的性能要求，比如OLAP程序经常需要求和和计算，为了性能，这些派生字段是必须的存在。

　　从上图中，您可以看到 Average 字段如何依赖于 Marks 和 Subjects 字段。这也是一种冗余形式。因此，对于从其他领域获得的此类领域，需要思考它们是否真的需要存在。

　　这条规则也被称为“三种范式”中的第三条规则：“不应该有依赖于非主键的列”。我个人的意见是不要盲目套用这条规则，应该看实际情况，冗余数据并不总是坏事。如果计算出冗余数据，在决定是否应用此第三范式之前，请先查看实际情况。

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

　　不要将“避免冗余”作为绝对规则来遵循。如果迫切需要性能，请考虑打破规则。一般情况下，需要对多张表做join操作，而在非常规的情况下，这样的多表join会大大降低性能。

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

　　OLAP项目主要是解决多维数据问题。例如，如果您查看下面的图表，您将希望获得每个国家、每个客户、每个时期的销售额。简单地说，您正在查看的销售数据收录三个维度的交集。

　　针对这种情况进行实际设计是一种更好的方法。简而言之，您可以创建一个收录销售字段的简单主销售表，并通过外键连接所有其他不同维度的表。

　　规则10：统一设计具有“名值表”特征的表

　　我多次遇到过这个“名称-值表”。“名称-值表”意味着它具有与其他数据相关的键。例如，在下面的图表中，您可以看到我们有两个表，Currency（货币）和 Country（国家/地区）。如果您仔细观察，您会发现这些表实际上只有键和值。

　　对于这种表，创建一个带有类型字段的主表来区分不同的数据会更有意义。

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

　　我们经常遇到具有无限父子层次结构（树结构？）的数据。例如，考虑一个多层次的销售计划，其中一个销售人员可以有多个销售人员。请注意，他们都是“销售人员”。也就是说，数据本身就是一种。但是级别不同。这时候我们就可以把自己的主键称为外键来表达这种层次关系，从而达到我们的目的。

　　这个文章的目的不是告诉你不要遵循范式，而是告诉你不要盲目地遵循范式。根据项目的性质和需要使用的数据类型做出正确的选择。