无论您是使用包含数百条记录还是数百万条记录的数据库，正确的数据库设计始终都很重要。它不仅可以更轻松地检索信息，而且还可以简化将来扩展数据库的过程。不幸的是，很容易陷入一些可能使未来变得困难的陷阱。
有关于规范化数据库的主题的全部书籍，但如果您只是避免这里显示的常见错误，您将走上正确的数据库设计轨道。
数据库错误＃1：重复表中的字段
良好的数据库设计的基本经验法则是识别重复数据并将这些重复列放在自己的表中。对于那些来自电子表格世界的人来说，重复表格中的字段很常见，但是虽然电子表格在设计上往往是扁平的，但数据库应该是关系型的。这就像从2D到3D。
幸运的是，重复的字段通常很容易被发现。看看这个表：
| 订单ID | 产品1 | 产品2 | 产品3 |
| 1 | 泰迪熊 | 果冻豆 | |
| 2 | 果冻豆 |
当订单包含四种产品时会发生什么？我们需要在表中添加另一个字段以支持三种以上的产品。如果我们围绕表格构建了一个客户端应用程序来帮助我们输入数据，我们可能需要使用新的产品字段对其进行修改。我们如何在订单中找到所有与Jellybeans的订单？我们将被迫查询表中的每个产品字段，其中的SQL语句可能如下所示：SELECT * FROM Products WHERE Product1 ='Jelly Beans'OR Product2 ='Jelly Beans'OR Product3 ='Jelly Beans'。
我们应该有三个表，每个表都包含一个独特的信息，而不是只有一个表将所有信息填充在一起。在这个例子中，我们希望Orders表包含有关订单本身的信息，包含所有产品的Products表和将产品链接到订单的ProductOrders平板电脑。
| 订单ID | 顾客ID | 订购日期 | 总 |
| 1 | 7 | 1/24/17 | 19.99 |
| 2 | 9 | 1/25/17 | 24.99 |
| 产品ID | 产品 | 计数 |
| 1 | 泰迪熊 | 1 |
| 2 | 果冻豆 | 100 |
| ProductOrderID | 产品ID | 订单ID |
| 101 | 1 | 1 |
| 102 | 2 | 1 |
请注意每个表如何具有自己的唯一ID字段。这是主键。我们使用主键值作为另一个表中的外键来链接表。阅读有关主键和外键的更多信息。
数据库错误＃2：在表中嵌入表
这是另一个常见的错误，但它并不总是与重复的字段一样突出。在设计数据库时，您需要确保表中的所有数据都与自身相关。就像那个孩子关于发现不同之处的游戏一样。如果你有香蕉，草莓，桃子和电视机，电视机可能属于其他地方。
同样，如果您有销售人员表，则该表中的所有信息都应与该销售人员具体相关。对于该销售人员而言不是唯一的任何额外信息可能属于数据库中的其他位置。
| SalesID | 第一 | 持续 | 地址 | 电话号码 | 办公室 | OfficeNumber |
| 1 | 山姆 | 埃利奥特 | 118 Main St，Austin，TX | (215) 555-5858 | 奥斯汀市中心 | (212) 421-2412 |
| 2 | 爱丽丝 | 工匠 | 纽约州纽约市第二街504号 | (211) 122-1821 | 纽约（东） | (211) 855-4541 |
| 3 | 乔 | 教区 | 428 Aker St，Austin，TX | (215) 545-5545 | 奥斯汀市中心 | (212) 421-2412 |
虽然这个表可能看起来都与个人销售人员有关，但它实际上在表中嵌入了一个表。注意Office和OfficeNumber如何重复“奥斯汀市中心”。如果办公室电话号码改变怎么办？您需要为一条信息更改更新一整套数据，这绝不是一件好事。应将这些字段移动到自己的表中。
| SalesID | 第一 | 持续 | 地址 | 电话号码 | OfficeID |
| 1 | 山姆 | 埃利奥特 | 118 Main St，Austin，TX | (215) 555-5858 | 1 |
| 2 | 爱丽丝 | 工匠 | 纽约州纽约市第二街504号 | (211) 122-1821 | 2 |
| 3 | 乔 | 教区 | 428 Aker St，Austin，TX | (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第二街 | 纽约 | 纽约 | 10022 | 2111221821 | |
| 3 | 乔 | 教区 | 428 Aker St | Apt 304 | 奥斯汀 | TX | 78716 | 2155455545 |
这里有几点需要注意。首先，“地址1”和“地址2”似乎属于重复字段错误。
但是，在这种情况下，它们指的是与销售人员直接相关的单独数据，而不是应该在其自己的表中的重复数据组。
此外，作为避免的额外错误，请注意电话号码的格式是如何从表格中删除的。你应该尽可能避免存储字段的格式。对于电话号码，人们可以通过多种方式编写电话号码：215-555-5858或（215）555-5858。这将使得通过他们的电话号码搜索销售人员或者在相同的区域代码中搜索销售人员更加困难。
数据库错误＃4：未使用正确的主键
在大多数情况下，您需要为主键使用自动递增的数字或其他生成的数字或字母数字。您应该避免使用主键的任何实际信息，即使它听起来像是一个好的标识符。
例如，我们每个人都有自己的社会安全号码，因此使用员工数据库的社会安全号码可能听起来不错。但是，虽然罕见，但即使社会安全号码也可能发生变化，我们也不希望我们的主键发生变化。
这就是使用实际信息作为关键值的问题。它可以改变。
数据库错误＃5：不使用命名约定
当您第一次开始设计数据库时，这可能听起来不是什么大问题，但是一旦您开始针对数据库编写查询以检索信息，在记忆字段名称时使用命名约定将有所帮助。
试想一下，如果将名称存储为一个表中的FirstName，LastName和另一个表中的first_name，last_name，那么该过程会变得多么困难。
两个最流行的命名约定是将字段中每个单词的首字母大写或使用下划线分隔单词。您可能还会看到一些开发人员将除了第一个单词之外的每个单词的第一个字母大写：firstName，lastName。
您还需要决定使用单数表名称还是多个表名称。它是Order表还是Orders表？它是Customer表还是Customers表？同样，您不希望被Order表和Customers表所困扰。
您选择的命名约定并不像实际选择和坚持命名约定的过程那么重要。
数据库错误＃6：索引不正确
索引是最难解决的问题之一，特别是对于数据库设计方面的新手。应索引所有主键和外键。这些是将表链接在一起的，因此如果没有索引，您将看到数据库的性能非常差。
但是经常错过的是其他领域。这些是“WHERE”字段。如果您经常通过使用WHERE子句中的字段来缩小搜索范围，则需要考虑在该字段上放置索引。但是，您不希望过度索引表，这也会损害性能。
怎么决定？这是数据库设计艺术的一部分。您应该在表上放置多少索引没有硬性限制。首先，您希望索引WHERE子句中经常使用的任何字段。阅读有关正确索引数据库的更多信息。
