问题标签 [denormalization]

对于像 stackoverflow 这样的高流量网站，数据库设计和规范化的最佳实践是什么？

应该使用规范化数据库进行记录保存还是使用规范化技术或两者兼而有之？

设计一个规范化数据库作为记录保存的主数据库以减少冗余并同时维护另一种非规范化形式的数据库以进行快速搜索是否明智？

或者

是否应该对主数据库进行非规范化但在应用程序级别使用规范化视图以实现快速数据库操作？

或其他方法？

作为这个问题的必然结果，我想知道是否有很好的比较研究，我可以咨询并传递关于使用 RDMBS 进行连接优化与系统非规范化以便始终一次访问单个表的优势。

具体来说，我想了解以下信息：

• 性能或规范化与非规范化。
• 规范化与非规范化系统的可扩展性。
• 非规范化的可维护性问题。
• 非规范化的模型一致性问题。

有点历史，看看我要去哪里：我们的系统使用内部数据库抽象层，但它很旧，不能处理多个表。因此，所有复杂对象都必须在每个相关表上使用多个查询来实例化。现在，为了确保系统始终使用单个表，在整个表中都使用了大量的系统非规范化，有时会压平两到三层深度。至于 nn 关系，他们似乎已经通过精心设计他们的数据模型来解决它，以避免这种关系，并且总是退回到 1-n 或 n-1。

最终结果是一个错综复杂的系统，客户经常抱怨性能。在分析这样的瓶颈时，他们从不质疑系统所基于的这些基本前提，并且总是寻找其他解决方案。

我错过了什么 ？我认为整个想法是错误的，但不知何故缺乏无可辩驳的证据来证明（或反驳）它，这就是我求助于你们的集体智慧来指引我走向好的、被广泛接受的文学作品，这些文学作品可以说服我团队中的其他成员方法是错误的（让我相信我对一致的数据模型过于偏执和教条）。

我的下一步是建立自己的测试平台并收集结果，因为我讨厌重新发明轮子，我想知道这个主题已经有了什么。

---- 编辑注释：该系统最初是用平面文件构建的，没有数据库系统......只是后来它被移植到数据库，因为客户坚持使用 Oracle 的系统。他们没有重构，只是简单地为现有系统添加了对关系数据库的支持。平面文件支持后来被删除，但我们仍在等待重构以利用数据库。

我在这里的第一个问题，所以很好！

我是一名经验不足的初级开发人员，在解决这个问题时遇到了麻烦。

我有一张需要审核的表格。假设此表记录呼叫中心拨打的电话（不是，但这只是一个示例）。我称之为“CallHistory”。

我最初计划保留一个名为“Callees”的单独表，其中包含被调用者的姓名、电话号码等。该表将使用代理主键。

CallHistory 表将具有 Callee 表的外键。

我最初这样做是为了如果我更改了被叫方的电话号码，它将在整个系统中传播，我不必在多个表中更改电话号码。

问题是，CallHistory 表的全部意义在于记录呼叫历史，包括误拨电话（比如呼叫者拨错号码）。使用这种代理键方法会丢失历史记录。

工作中的一位高级开发人员建议在 CallHistory 表中保留呼叫者在该特定时间每次拨打电话的电话号码副本，以保存历史记录。

我正在考虑为同样的目的保留一个审计/更改日志表。

我的方法是否足以满足这个目的，还是我完全偏离了轨道？您更喜欢哪种方法？

干杯，安德鲁

我试图在实现小型 SQL Server '08 数据库时做出判断。

我正在将平面文件数据库的输出文本文件从旧的 COBOL 系统转换为上述 SQL Server 数据库。它是一个车辆和房地产贷款数据库，可以通过 Lender ID（七位数）、银行帐号（15 位数）和“账户后缀”（两位数）的组合来唯一标识。

我承认我在数据库管理方面非常天真（老实说，直到我现在的职位才真正做到这一点），并且我正在尝试确定两种方法中哪一种是我实施的最佳选择将索引到其他几个表的键：

1) 使用上述值的三列键标识每笔贷款，或
2) 通过实施“键”列来非规范化数据，该列是组合三个值的 24 个字符的字符串。

非规范化是丑陋的，当然，但我无法预料会发生更新异常，因为贷款无法在银行之间来回传递或更改其贷款后缀。这些值的变化保证是不同的帐户。

复合键更优雅，但我读过一些论文表明它是一件坏事。

那么，哪个选项可能是更好的选择，更重要的是，为什么？

我经常发现自己在编写这样的代码：

歌曲.rb：

即，sortable_name为了方便起见，我有一个包含非规范化数据的数据库列，并且我想在模型名称更改时填充它。

我希望能够将此逻辑封装在这样的构造中

或者其他的东西。这存在吗？

假设我让用户检查她说的语言并将其存储在数据库中。重要的附注，我不会在 db 中搜索任何这些值，因为我将有一些单独的搜索引擎进行搜索。现在，存储这些值的明显方法是创建一个表，如

但是该站点将是高负载的，我们正在尝试尽可能消除任何开销，因此为了避免在 UI 上显示结果时与主成员表连接，我正在考虑将用户的语言存储在主表中，让它们逗号分隔，如“12,34,65”

同样，我不搜索它们，所以我不必担心必须对该列进行全文索引。

我真的没有看到这个解决方案有任何问题，但是我忽略了什么吗？

谢谢，安德烈

我正在使用 Rails 和 MySQL，并且有一个基于行计数的效率问题。

我有一个Project模型has_many :donations。

我想计算一个项目的唯一捐助者的数量。

在projects表中有一个名为的字段num_donors，并在创建新的捐助者时增加它是一个好主意吗？

或者@num_donors = Donor.count(:select => 'DISTINCT user_id')由于数据库优化，在效率方面是否会变得相似或相同？这是否需要我为user_id我想要计算的任何其他字段创建索引？

对捐赠的总金额求和是否同样的答案？

我开始了一个新项目，他们有一个非常规范化的数据库。可以查找的所有内容都存储为查找表的外键。这是规范化的，很好，但我最终为最简单的查询做了 5 个表连接。

我想建议我们对一些东西进行去规范化。就像州代码一样。在我的一生中，我没有看到州代码发生变化。与 3 个字母的机构代码类似的故事。这些是由机构的机构分发的，永远不会改变。

当我以状态代码问题和 5 个表连接联系 DBA 时。我得到“我们已标准化”和“加入速度很快”的响应。

是否有令人信服的非规范化论点？如果没有别的，我会为了理智而这样做。

T-SQL 中的相同查询：

目前的情况是主题按3个主要类别排序。有可能添加不止 3 个类别，但上级希望实现在主题中添加不止 1 个类别的功能。

我的原始数据库设计将 categoryID 作为主题信息表中的外键。从一开始这可能是一个坏主意，但我认为他们只设置了 3 个类别，并且这样做可以减少查询。

所以从我所看到的我现在有两个选择：1）输入categoryID作为我在php端解析的逗号分隔字符串。2）重构DB，将categoryID拉出到自己的categoryID和topicID表中。

我想知道每个人对此有何看法。我的第一反应是重组数据库。但是当我想到它时，第一个选项是最容易实现的，并且最不可能通过更改数据库来破坏现有的东西。然而，这也可能导致反规范化并打开数据不一致的可能性。

我已经阅读过，只要您接受数据不一致以换取性能的风险，反规范化就可以了。在您看来，我是否会因为这种风险而获得很大的绩效？任何关于我在这种情况下应该做什么的意见将不胜感激。

谢谢你的帮助，
列维

概述 （对不起，它含糊不清 - 我认为如果我更详细地介绍它会使事情变得过于复杂）

我有三个表，表一包含一个ID，表二包含它自己的ID和表一的ID，表三包含它自己的ID和表二的ID。

我花了很多时间思考，我认为表三也包含相关的表ID会更有效。

- 这意味着我不必连接三个表，我可以只查询表三（对于经常使用的查询）

- 这将允许我通过仅锁定表 3 中包含表 1 中特定 id 的行来更轻松地实现预订系统。

对于任何想了解更多关于数据库布局的人来说，这里有更多信息

问题

去规范化有哪些不利条件？我见过一些人完全反对它，而另一些人则认为在正确的情况下它是一个有用的工具。id 永远不会改变，所以我真的没有看到任何缺点，除了必须插入两次相同的数据，因此它会消耗额外的空间（因为它只是 id 肯定可以忽略不计）。