无论您使用的是拥有数百条记录还是数百万条记录的数据库,正确的数据库设计总是非常重要。 它不仅可以更轻松地检索信息,还可以简化未来扩展数据库的工作。 不幸的是,很容易陷入一些可能会使事情变得困难的陷阱。
关于规范化数据库的主题有整本书,但如果您只是避免这些常见错误,那么您将会走上正确的轨道,进行良好的数据库设计。
数据库错误#1:重复表中的字段
良好数据库设计的基本经验法则是识别重复数据并将这些重复列置于其自己的表中。 在表格中重复字段对于那些来自电子表格世界的人来说很常见,但尽管电子表格设计趋于平坦,但数据库应该是关系型的。 这就像从2D到3D。
幸运的是,重复的领域通常很容易被发现。 只要看看这个表格:
订单ID | 产品1 | 产品2 | 产品3 |
1 | 泰迪熊 | 软糖豆 | |
2 | 软糖豆 |
当订单包含四种产品时会发生什么? 我们需要在表中添加另一个字段以支持三种以上的产品。 如果我们在表格周围建立了客户端应用程序来帮助我们输入数据,那么我们可能需要使用新产品字段对其进行修改。 我们如何在订单中找到所有与糖果豆的订单? 我们将被迫使用可能如下所示的SQL语句来查询表中的每个产品字段:SELECT * FROM Products WHERE Product1 ='Jelly Beans'或Product2 ='Jelly Beans'或Product3 ='Jelly Beans'。
我们应该有三个表格,每个表格都包含一个独特的信息,而不是将所有信息放在一起。 在这个例子中,我们需要一个订单表,其中包含有关订单本身的信息,包含我们所有产品的产品表以及将产品链接到订单的ProductOrders平板电脑。
订单ID | 客户ID | 订购日期 | 总 |
1 | 7 | 17年1月24日 | 19.99 |
2 | 9 | 17年1月25日 | 24.99 |
产品ID | 产品 | 计数 |
1 | 泰迪熊 | 1 |
2 | 软糖豆 | 100 |
ProductOrderID | 产品ID | 订单ID |
101 | 1 | 1 |
102 | 2 | 1 |
请注意每个表格如何拥有自己唯一的ID字段。 这是主键。 我们通过将主键值用作另一个表中的外键来链接表。 阅读有关主键和外键的更多信息。
数据库错误#2:在表中嵌入表
这是另一个常见的错误,但它并不总是像重复领域一样突出。 在设计数据库时,您需要确保表中的所有数据都与自身相关。 这就像那个孩子关于发现不同的游戏一样。 如果你有香蕉,草莓,桃子和电视机,电视机可能属于别的地方。
换句话说,如果你有一张销售人员表,那么表中的所有信息都应与该销售人员具体关联。 任何不是该销售人员唯一的额外信息可能属于数据库中的其他位置。
SalesID | 第一 | 持续 | 地址 | 电话号码 | 办公室 | OfficeNumber |
1 | 山姆 | 埃利奥特 | 德克萨斯州奥斯汀市118 Main St | (215)555-5858 | 奥斯汀市区 | (212)421-2412 |
2 | 爱丽丝 | 工匠 | 第二街504号,纽约,纽约 | (211)122-1821 | 纽约(东部) | (211)855-4541 |
3 | 乔 | 教区 | 428 Aker St,德克萨斯州奥斯汀市 | (215)545-5545 | 奥斯汀市区 | (212)421-2412 |
虽然这张表看起来可能与个别销售人员有关,但实际上它有一张嵌入表格的表格。 请注意Office和OfficeNumber如何重复“Austin Downtown”。 如果办公室电话号码发生变化会怎样 您需要更新一整套数据以更改单个信息,这绝不是一件好事。 这些字段应该移到他们自己的表格中。
SalesID | 第一 | 持续 | 地址 | 电话号码 | OfficeID |
1 | 山姆 | 埃利奥特 | 德克萨斯州奥斯汀市118 Main St | (215)555-5858 | 1 |
2 | 爱丽丝 | 工匠 | 第二街504号,纽约,纽约 | (211)122-1821 | 2 |
3 | 乔 | 教区 | 428 Aker St,德克萨斯州奥斯汀市 | (215)545-5545 | 1 |
OfficeID | 办公室 | OfficeNumber |
1 | 奥斯汀市区 | (212)421-2412 |
2 | 纽约(东部) | (211)855-4541 |
这种类型的设计还使您能够向Office表添加更多信息,而不会在销售人员表中创建混乱的噩梦。 想象一下,如果所有这些信息都在销售人员表中,只需跟踪街道地址,城市,州和邮政编码就可以完成多少工作!
数据库错误#3:将两条或更多条信息放入单个字段中
将办公信息嵌入到销售人员表中并不是该数据库的唯一问题。 地址栏包含三条信息:街道地址,城市和州。 数据库中的每个字段只能包含一条信息。 当您在单个字段中有多条信息时,查询数据库信息会变得更加困难。
例如,如果我们想要对奥斯汀的所有销售人员进行查询,该怎么办? 我们需要在地址字段内进行搜索,这不仅效率低下,而且会返回不良信息。 毕竟,如果有人住在俄勒冈州波特兰的奥斯汀街上,会发生什么?
以下是该表的外观:
SalesID | 第一 | 持续 | 地址1 | 地址2 | 市 | 州 | 压缩 | 电话 |
1 | 山姆 | 埃利奥特 | 118 Main St | 奥斯汀 | TX | 78720 | 2155555858 | |
2 | 爱丽丝 | 工匠 | 504 2nd St | 纽约 | 纽约 | 10022 | 2111221821 | |
3 | 乔 | 教区 | 428 Aker St | 公寓304 | 奥斯汀 | TX | 78716 | 2155455545 |
这里有几件事需要注意。 首先,“Address1”和“Address2”似乎属于重复性字段错误。
然而,在这种情况下,他们指的是直接与销售人员相关的单独数据片段,而不是应该在其自己的表格中重复出现的重复数据组。
此外,作为避免的一种奖励错误,请注意电话号码的格式已从表格中删除。 尽可能避免存储字段的格式。 在电话号码的情况下,人们可以通过多种方式输入电话号码:215-555-5858或(215)555-5858。 这将使得通过他们的电话号码搜索销售人员或在相同区域代码中搜索销售人员更加困难。
数据库错误#4:不使用正确的主键
在大多数情况下,您需要为主键使用自动递增的数字或其他生成的数字或字母数字。 你应该避免使用主键的任何实际信息,即使它听起来像是一个好的标识符。
例如,我们每个人都有我们自己的个人社会安全号码,因此使用员工数据库的社会安全号码听起来可能是一个好主意。 但虽然很少见,但即使是社会安全号码也有可能发生变化,我们永远不希望我们的主键发生变化。
这是将实际信息用作关键值的问题。 它可以改变。
数据库错误#5:不使用命名约定
当你第一次开始设计你的数据库时,这可能听起来不是什么大不了的事,但是一旦你开始写数据库查询来检索信息,命名约定会帮助你记住字段名。
试想一下,如果名字在一个表中存储为FirstName,LastName,而在另一个表中存储first_name,last_name,那么过程会更困难。
两种最流行的命名约定是大写字段中每个单词的第一个字母或使用下划线分隔单词。 您可能还会看到一些开发人员利用除第一个单词之外的每个单词的第一个字母:firstName,lastName。
您还需要决定使用单数表名还是复数表名。 它是订单表还是订单表? 它是客户表还是客户表? 同样,您不希望陷入订单表和客户表。
您选择的命名约定与实际选择和坚持命名约定的过程并不重要。
数据库错误#6:索引不当
编制索引是最难的事情之一,特别是对于数据库设计人员来说更是如此。 所有的主键和外键都应该被索引。 这些是链接在一起的表,所以如果没有索引,你会看到数据库性能很差。
但其他领域往往错过了。 这些是“WHERE”字段。 如果您经常要通过在WHERE子句中使用字段来缩小搜索范围,则您需要考虑在该字段上放置索引。 但是,您不想过度索引表格,这也会影响表现。
如何决定? 这是数据库设计艺术的一部分。 对于应该放在桌子上的索引数量没有限制。 主要的是,你想索引在WHERE子句中经常使用的任何字段。 详细了解如何正确索引数据库。