好的我知道你可能都会因为问这个问题而杀了我，但是我和一位同事讨论了一个关于我们数据库表的友好程序员问题，他问了一个我知道答案的问题但是我无法解释这是更好的方式。
我将简化问题的简单情况，我们有一个相当大的人/用户表。现在存储的其他数据中有问题的数据如下：我们有一个simNumber，cellNumber和该sim的ipAddress。
现在我说我们应该创建一个表，让我们称之为SimTable并将这3个条目放入sim表中，然后在UsersTable中放入一个FK链接两者。为什么？因为那是我一直以来所教授的，所以你的桌子！好的，所以在这方面都很好。
但现在我的朋友对我说是的，但现在当你想查询用户的电话号码时，SQL现在必须去：
现在，当我去请求10000个用户的电话号码时，所做的操作数量会严重增加。
采用另一种方法
现在这个论点纯粹基于表现。尽管我理解为什么我们会对数据进行规范化（删除冗余数据，可维护性，在一个表中对数据进行更改等等）。在我看来，在一个表中使用数据的方法会更快或者至少会减少任务/操作来提供我想要的数据？
那么这种情况是怎样的呢？我希望我没有问过任何疯狂的傻事，这是一大早所以如果我不清楚的话，请原谅我
MS SQL server 2012中涉及的技术
[编辑] 下面的这篇文章也涉及我上面提到的一些概念 http://databases.about.com/od/specificproducts/a/Should-I-Normalize-My-Database.htm
答案 0 :(得分：6)
规范化的目标不是表现。目标是以最小的冗余度正确建模数据，以避免数据异常。
例如，假设两个用户共享同一部手机。如果将电话存储在用户表中，则每个用户的行中都存有SIM号，IP地址和单元号。
然后更改一行的IP地址，而不更改另一行的IP地址。一个sim号码如何有两个IP地址？这甚至有效吗？哪一个是正确的？你会如何解决这些差异？你怎么会发现它们？
如果您确实需要针对一个经常运行的查询优化数据访问，有时非规范化是值得的。但非规范化需要付出代价，因此请准备好承担更多的手工工作，以承担数据完整性的责任。更多代码，更多测试，更多清理任务。在考虑＆＃34;性能＆＃34;整个项目？
评论：
我同意@JoelBrown，一旦实施了第一个非规范化案例，就会对数据完整性做出妥协。
我将扩展乔尔提到的＃34;经过深思熟虑。＆＃34;非规范化有利于特定的查询。因此，您需要知道应用中有哪些查询，以及需要针对哪些查询进行优化。保守地执行此操作，因为虽然非规范化可以帮助特定查询，但会损害性能以用于相同数据的所有其他用途。因此，您需要知道是否需要以不同方式查询数据。
示例：假设您正在为StackOverflow设计数据库，并且您希望支持问题的标记。每个问题都可以包含多个标记，每个标记都可以应用于许多问题。设计这个的标准化方法是创建第三个表，将问题与标签配对。这是多对多关系的物理数据模型：
Questions ----<- QuestionsTagged ->---- Tags
但是您认为您不想进行连接以获取给定问题的标记，因此您将标记放入问题表中以逗号分隔的字符串中。这使得查询给定问题及其相关标签变得更快。
但是，如果您还想查询一个特定标签并找到相关问题，该怎么办？如果您使用规范化设计，它只是针对多对多表格的查询，但在tag列上。
但是如果通过在“问题”表中将标记存储为逗号分隔列表来进行非规范化，则必须在该逗号分隔列表中搜索标记作为子字符串。搜索子字符串不能使用标准B树样式索引编制索引，因此搜索相关问题会成为代价高昂的表扫描。插入和删除标记，或应用唯一性或外键等约束也会更加复杂和低效。
我的意思是非规范化，以牺牲数据的其他用途为代价来改进一种类型的查询 。这就是为什么以正常形式开始使用所有内容然后根据具体情况重构非规范化设计的原因，因为你的瓶颈会显露出来。
这可以追溯到古老的智慧：
＆＃34;过早优化是所有邪恶的根源＆＃34; - Donald Knuth
换句话说，不要进行反规范化，直到您可以在负载测试期间证明：（a）它对性能进行了真正的改进，证明了数据完整性的损失，并且（b）它不会降低其他性能的性能案件令人无法接受。
答案 1 :(得分：1)
听起来你已经明白了规范化的好处，所以我不会覆盖这些。
这里有几个注意事项： 1.用户是否始终拥有唯一的电话号码？ 如果是这样，那么它仍然被标准化以将这些添加到用户表。但是，如果用户可以没有电话号码或多个电话号码，则电话详细信息应保存在单独的表格中。
答案 2 :(得分：1)
其他人已经提供了一些好处，您可能还想看看this。
我想再提一个经常被忽视的方面：I / O往往是大多数查询成本的最大组成部分，而非规范化通常会增加数据的存储大小，从而使得DBMS成为可能缓存＆＃34;较小＆＃34;。
如果您的规范化数据库适合缓存并且非规范化的数据库不适合，那么您实际上可能会观察到后者的性能减少。
除非您确实拥有与生产相似的数据量，否则您无法在开发过程中发现这一点。这是为什么你不应该在没有可靠测量的情况下（对有代表性的数据量）进行非规范化以证明其合理性的众多原因之一。