数据库触发器/引用完整性和内存缓存

Question

您是否看到数据库触发器/参照完整性规则的使用方式会更改数据库中的实际数据（更改表 x 中的行 w 会导致表 z 中的行 y 发生更改）？

如果是，这与内存缓存（memcache 和朋友）的日益普及有何关系？毕竟，这些操作发生在数据库内部，但缓存系统必须了解它们才能反映正确的状态（或至少使可能更改的状态无效）。我发现很难相信回调是针对这种情况实现的。

有没有人有这样的设置的实际经验/考虑这样的设置并放弃它的实际经验（你走了哪条路？如果缓存，你如何强制完整性？）

Answer 1

简单答案：

• 引用完整性是必须具备
• 缓存是合格必须具备
• 触发器最好拥有

<强>更长的答案

自 1993 年以来，我一直在关系数据库上开发应用程序（自从你问以来，Dec RDB，在那之前就在平面文件系统上），触发器从未受到许多开发人员的欢迎，因为它们可以“删除那些你不想删除'。引用完整性也常常被开发人员所不赞成，因为具有适当引用完整性的第三范式的数据库很难在几分钟内整合在一起。

缓存通常也被认为很难正确执行，尽管我不确定为什么。

虽然许多系统可以在没有触发器的情况下运行，但我想说没有应用程序数据库可以在没有引用完整性的情况下轻松生存。看看这个问题上的标签，该网站背后的数据库将有一个标签（可能称为“标签”）和问题（可能称为“问题”）的表格。 “问题”将有一个指向标签表上主键的外键，但由于问题可以有很多标签，而标签可以有很多问题，我猜这种关系是这样的：

   Question
   (TagId)         1 | Database triggers / referential integrity and in-memory caching
      |  
    -----
    | | |
  QuestionTag
 (QuestionId)       1 | 1  ... 1 | 2  ... 1 | 3 ...
    (TagId)
    | | |
    -----
      |
     Tag            1 | database ... 2 | referential-integrity ... 3 | triggers ...
   (TagId)

这种引用完整性是任何可靠的应用程序，都是没有商量余地的。您可以看到它如何增加应用程序设计的可信度和对其寿命的信心。

SO 上的缓存可能会针对标签之类的东西打开（尽管不能保证），因此假设标签已缓存在内存中，并且您有足够的信誉可以向 SO 添加标签。您添加标签，它很可能会立即保存到数据库中 - 但缓存会更新吗？

你所拥有的是一个权衡。在不知道您的新标签的情况下，该网站能否生存？如果会持续多久？从根本上来说，标签的生命周期是怎样的？从用户添加到数据库中、可供其他用户使用、被其他用户使用？缓存将根据开发团队制定的规则重建 - 该规则本质上是一种权衡，以便任何新标签都可以足够快地可用，而不会减慢应用程序的速度。

触发器可以强制引用完整性，假设您添加的标签是“垃圾”，但当管理员看到它时，三个问题都被标记为“垃圾”。然后，管理员决定删除“垃圾”标签 - 但是用它标记的问题又如何呢？如果“标签”表上有一个在删除时触发的触发器，那么它可以围绕“问题”表运行并删除所有对“垃圾”的引用。这种方法有很多替代方案 - 其中许多是程序化的解决方法 - 但有没有更干净的替代方案？

在过去的 20 年里，我在很多网站上工作过，好的网站都使用引用完整性并越来越多地使用缓存。匿名更改数据的触发器（它们本质上都是事件驱动的存储过程）并不流行，而且越来越被误解，但仍然发挥着作用。

缓存和引用完整性不能被视为非此即彼——开发团队必须设计应用程序，以便将两者结合起来。