数据库触发器/参照完整性和内存中缓存

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

如果是的话,这与内存缓存(memcache和朋友)的日益普及有什么关系呢？毕竟,这些操作发生在数据库内部,但缓存系统必须知道它们以反映正确的状态(或至少使可能更改的状态无效).我发现很难相信为这种情况实施了回调.

考虑到这样的设置并放弃它,有没有人拥有这种设置/现实世界体验的实际经验(你走哪条路？如果缓存,你如何强制执行完整性？)

简单回答:

参照完整性是必须的

缓存是必须具备的

触发是一件好事

更长的答案

自1993年以来,我一直在关系数据库上开发应用程序(自从你问到12月RDB以及之前的平面文件系统)和触发器从未受到许多开发人员的欢迎,因为他们可以"删除你不想删除的东西".开发人员经常不赞成参照完整性,因为具有适当参照完整性的第三范式的数据库很难在几分钟内完成.

虽然我不确定为什么,缓存通常也被认为是很难做到的.

虽然许多系统可以在没有触发器的情况下生存,但我认为没有参考完整性,任何应用程序数据库都无法轻松生存.看看这个问题上的标签,这个网站背后的数据库将有一个标签表(可能称为"标签")和问题(可能称为"问题").'问题'将有一个外键到Tag表上的主键,但由于问题可以有很多标签和标签可以有很多问题,我猜这种关系是这样的:

   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添加标签.你添加你的标签,它可能会立即持久存储到数据库 - 但缓存然后更新？

你所拥有的是一种权衡.网站可以在不知道您的新标签的情况下生存吗？如果是这样多久？从根本上说,标签的生命周期是什么,从用户添加到数据库,进入其他用户使用的其他用户？缓存将根据开发团队设置的规则进行重建 - 该规则将基本上是一种权衡,以便任何新标记都可以足够快地获得,而不会降低应用程序的速度.

触发器可以强制引用完整性,比如你添加的标签是"垃圾",但是当管理员看到它时,三个问题被标记为"垃圾".然后管理员决定删除"垃圾"标签 - 但是用它标记的问题呢？如果在'tag'表上有一个触发器在delete上触发,它可以围绕'question'表运行并删除对'rubbish'的所有引用.这种方法有很多替代方案 - 其中许多是程序化的工作环境 - 但是有更清洁的选择吗？

在过去的20年里,我在许多网站上工作过,好的网站使用参照完整性和越来越多的缓存.匿名更改数据的触发器(它们基本上都是事件驱动的存储过程)不受欢迎,并且越来越被误解,但仍然有作用.

缓存和参照完整性不能被认为是开发团队必须设计应用程序以便两者都可以合并.