【问题标题】:Buffer table in a database, Good or not?数据库中的缓冲表,好不好?
【发布时间】:2015-11-08 12:51:19
【问题描述】:

我有一个问题!

我需要做一个大学项目,在这个项目中我将有一个这样的数据库表:

这个表会有很多记录!!!!!! 为了管理这一点,我需要创建一个验证系统。

在创建这样的缓冲表之间最好(以及为什么):

或者像这样在我的表中添加一列:

谢谢!

【问题讨论】:

  • a LOT of records !!!!!!”是多少行?

标签: sql database database-schema


【解决方案1】:

您的问题没有足够的信息来提供真正的答案。这里有一些关于如何思考这种情况的指导。哪种方法取决于您的应用程序的性质,尤其是“验证”的含义。

一种合理的解释是“验证”是工作流程的一部分,因此它只发生一次(或 99% 的时间只发生一次)。而且,当您查看广告时,您永远不想看到未经验证的广告。如果是这种情况,那么通常会有关于验证过程的其他信息。

这种情况提出了两种合理的方法:

  • 在事务中进行验证。如果验证过程完全在数据库中并且以秒为单位进行测量,这将是合理的。
  • 有一个单独的表格用于验证广告。甚至可能为每个负责他们的“用户”或“实体”创建一个单独的表。根据验证过程的性质,这可能是一个将它们提供给进行验证的人的队列。

将它们放在“广告”表中没有意义,因为验证过程中可能涉及其他信息——谁、什么、在哪里、何时、如何。

如果一个广告可以多次验证和无效,那么最好的方法可能是将它们放在同一个表中。再一次,对过程的性质存在疑问。

在没有全表扫描的情况下访问这两个组是很棘手的。如果 10% 的行无效且 90% 的行已验证,则正常索引将需要全表扫描来读取任一组。为了更快地访问较小的组,这里有两个选项:

  • 验证标志上的聚集索引。
  • 为已验证和已失效的行单独分区。

在这两种情况下,更改记录的验证标志相对昂贵,因为它涉及在不同数据页上读取和写入记录。除非每秒进行数十次更改,否则这可能没什么大不了的。

【讨论】:

  • 他可以创建一个以valid作为前导列的索引来代替分区,从而获得100%的扫描效率。分区在这里似乎是一种核选择。删除分区或不同存储等常用功能都不是很有用。
  • +1 这实际上是正确的思考方式。 @usr 它是否实用可能取决于一些外部因素——如果验证实际上是实际工作流程的一部分,无论如何都将要实施,那么没有理由不以这种方式做事这就是我在我的回答中暗示它可能会使编码更加复杂——但如果您需要在应用程序代码中使用工作流,那么情况已经如此。
  • 是的,如果工作流程需要它,那当然是一个加分项,但它不会强制解决问题。为工作流的所有状态提供一个表会非常方便。毕竟,“项目”是否被“验证”并不会改变项目的身份。这只是一个不同的状态。示例:如果一个订单可以有 10 个州,您将不会打开 10 个表。
  • 感谢您的回答!!!实际上,验证过程会发生一次。如果一个广告没有被验证,它就会被销毁。非常感谢!
【解决方案2】:

在这里,不需要单独的“缓冲表”。您可以正确索引 valid 字段。所以下面的索引本质上会自动创建一个缓冲表:

create unique index x on y (id)
  include (all columns)
  where (valid = 0)

此索引会创建无效数据的副本。你可以做很多变化,比如

create unique index x on y (valid, id)

真的不需要单独的表。与分区甚至手动分区相比,索引非常容易。更少的工作,更通用,更灵活,更少的人为错误。

【讨论】:

  • 这是否合理完全取决于所使用的数据库——并不是所有的数据库系统都像其他系统一样顺利地处理索引,特别是在复杂的查询中,一个不够智能的查询计划器可能会丢弃索引并运行对整个表进行顺序扫描,可能是由于中间排序造成混淆,或者只是成本估算调整不当。
  • 是的。我不假思索地假设了 SQL Server。但是这个场景真的很简单,所以我不确定会出现什么问题。您的示例原则上是有效的,但我认为它们不太可能。在一个明显有选择性的列上建立索引似乎是最简单的事情。
【解决方案3】:

任何一种方法都是有效的,哪种方法性能更好将更多地取决于您使用的数据库类型,而不是使用布尔值或将其划分为两个表是否更正确的理论问题。

我实际上更喜欢分区方法(您的缓冲表想法),但是编码会更复杂。这可能是需要考虑的重要一点。 大多数现代数据库都可以通过索引很好地处理布尔标准,但有时您可能会感到惊讶。

从开发的角度来看,现在最重要的事情是选择一个并运行它,而不是在您决定“正确”的一个时使您的项目瘫痪。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2014-02-08
    • 1970-01-01
    • 2011-01-30
    • 1970-01-01
    相关资源
    最近更新 更多