5

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

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

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

4

1 回答 1

5

简单的答案：

  • 参照完整性是必须具备的
  • 缓存是合格的必备品
  • 触发器很不错

更长的答案

自 1993 年以来，我一直在关系数据库上开发应用程序（自您问起，为 12 月 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 年里，我在很多网站上工作过，好的网站使用参照完整性和越来越多的缓存。匿名更改数据的触发器（它们基本上都是事件驱动的存储过程）并不流行并且越来越多地被误解，但仍然发挥作用。

缓存和引用完整性不能被认为是非此即彼的——开发团队必须设计应用程序，以便可以合并两者。

于 2010-03-15T23:14:15.167 回答