【问题标题】:Best Practices: Redundant data or multiple joins?最佳实践:冗余数据或多个连接?
【发布时间】:2013-07-05 18:32:05
【问题描述】:

假设您有以下表格:OrdersCustomersEventsLines线路分配。我可以修改的唯一表是 LineAssignments 表。

  • 事件 1 * 订单
  • 客户 1 * 订单
  • 订单 1 * LineAssignments
  • 第 1 行 * LineAssignments

不同的页面显示不同的信息组合与行分配。例如,在某些页面上我只显示带有线路分配的事件信息,而在其他页面上我显示带有它们的订单信息等。

基本上,每当我添加新的线路分配时,我是否也应该存储 EventIDCustomerIDOrderID,还是应该仅存储 OrderID,然后进行多次连接以获取其他数据。创建一个连接这些表的视图会更好吗?

【问题讨论】:

    标签: sql linq-to-entities


    【解决方案1】:

    我倾向于遵循这样一种观点,即数据只能在数据库中表示一次。这意味着,在你的位置,我会尝试从多个连接中获取我需要的内容,并且只存储 OrderID。

    我这样做的原因是,如果存储在其他表中的数据(您复制到 LineAssignments 表中的数据)有可能被更新,则复制的数据将是错误的。我认为其他表中的数据不太可能发生变化,但如果发生这种情况的可能性不大……与可能不正确的数据相比,使用连接会更好。

    【讨论】:

      【解决方案2】:

      这只是一个性能问题。一般来说,你应该坚持 3NF,即没有冗余。虽然这提供了非常紧凑和优雅的数据结构,但它也可能导致严重的性能问题。

      如果您的数据库既用于生产数据又用于历史数据,即随着时间的推移而增长,通常会出现这种情况。

      发出联合查询时,您的 RDBMS 会将尽可能多的信息加载到内存中,通常是索引信息以加快查询速度。现在,如果您的索引太大以至于无法放入内存,那么您的 RDBMS(不,实际上是操作系统)将不得不交换,这是性能杀手。

      真正的交易(在我看来)是将生产数据(例如未结/未付订单)与历史数据完全分开。历史数据可以而且应该针对快速检索进行优化,因为不再有任何变化,而且硬盘很便宜。

      生产性数据应该是好的和紧凑的 (3.NF)。每当一条信息不再生产时(已支付订单、交付零件等),它将从生产数据库中删除并转移到历史数据中。

      获取有关“数据仓库”主题的信息,以防您还不熟悉它并阅读这些概念。这很容易理解。

      【讨论】:

        猜你喜欢
        • 2013-07-07
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2023-03-17
        • 1970-01-01
        • 2015-03-25
        • 2013-02-14
        • 2011-03-05
        相关资源
        最近更新 更多