【问题标题】:Chain of tables, when to denormalize?表链,何时非规范化?
【发布时间】:2012-01-20 00:20:30
【问题描述】:

假设TABLE-A可以在TABLE-B中有一行或多行,TABLE-C中可以有一行或多行,TABLE-D中可以有一行或多行......等等。

假设我在 TABLE-Z,需要了解有关 TABLE-A 的详细信息。我是否要进行从 TABLE-Z 一直到 TABLE-A 的 SQL 查询?在某些时候,如果 TABLE-Z 对 TABLE-A 有一个 FK,这样查询就不会那么痛苦,也许会很好。但是,如果我放那个 FK,我想我会打破正常化,对吧?

有关如何处理此问题的一般建议?

【问题讨论】:

    标签: mysql database-design normalization denormalization denormalized


    【解决方案1】:

    如果您使用复合主键(如果您在创建任何表之前正确建模设计,这实际上会发生),那么来自 TableA 的键已经包含在 TableZ 中(作为最左边的列)。

    但是,人们通常会在不了解为什么的情况下添加代理键。所以这需要加入所有 26 个表来建立 TableA 和 TableZ 之间的链接

    TableA 和您的 TableZ 之间的额外 FK 可能与某些中间外键冲突;这就是非规范化(或非规范化)数据具有固有风险的原因,应谨慎使用。

    但是,您通常不会有 26 层嵌套表。使用 2、3 甚至 6 路主键意味着我可以在没有任何中间表的情况下将 TableA 连接到 TableF。

    就个人而言,我会使用复合键并避免额外的 FK,除非我有一个已知的、可重现的和可证明的瓶颈。大多数数据库不会注意到任何差异。所以暂时不要优化

    【讨论】:

      【解决方案2】:

      在某些情况下,当查询的时间/内存使用比保持表的规范化更重要时,对表进行非规范化是可以接受的。假设您要选择数千行,从表 Z 一直到 A 将需要相当长的时间。

      基本上我会说这取决于你。如果保持表规范化很重要,请不要对它们进行非规范化。如果查询的速度和内存使用更重要,则应该对表进行非规范化。

      希望有帮助!

      【讨论】:

      • 所以这取决于这个“需要一段时间”的价值?
      • 通常是的。当然还有客户的意见和公司的规定等。如果你是为自己做一个项目,我会说你觉得最舒服。
      猜你喜欢
      • 2011-11-12
      • 1970-01-01
      • 1970-01-01
      • 2012-12-31
      • 1970-01-01
      • 1970-01-01
      • 2013-08-21
      • 2016-05-13
      • 2018-06-06
      相关资源
      最近更新 更多