mysql - 对于 "trashed"的对象，合适的表设计是什么

Question

我正在设计一个简单的媒体“服务器”作为更大应用程序的一部分。我选择采用与 AWS S3 服务类似的术语，即对象和存储桶(即文件和目录)。

我有两个表:

cdn_bucket
id, directory

和

cdn_object
id, bucket_id, filename, is_deleted

数据库中的其他表可以包含使用 cdn_object.id 上的外键的对象。这有很好的副作用，因为我可以指定一个约束，在对象被删除时将字段设置为 NULL(或者如果需要的话确实可以防止删除)。例如:

blog_post
id, title, body, featured_image
CONSTRAINT: featured_image = cdn_object.id ON DELETE SET NULL

有人告诉我，我永远不应该删除东西(这是另一篇文章的论点，请不要在这里发表评论)；因此有 is_deleted 标志。为了澄清这个问题，这就是我所说的“垃圾”，即可恢复。

这很好用，但是我无法利用约束的级联功能(即我将对象标记为已删除，但引用表，例如 blog_post.featured_image 引用旧 ID)。

我想知道 SO 对以下两种方法可能有什么看法，或者是否有另一种可能更好的方法。

1. Join the cdn_object table

SELECT bp.*, cdno.id featured_image FROM blog_post bp JOIN cdn_object cdno ON cdno.id = bp.featured_image AND cdno.is_deleted = 0.

Pro: easy to implement.

Con: every query has to join the cdn_object table.

或

2. Use a trash table

Have another table, cdn_object_trash and have the code 'move' the row cdn_object when it's deleted, triggering all the cascading constraints.

Pro: allows the relational rules to do what they were designed to do

Con: bad by design? Not sure.

我的直觉告诉我，我应该使用 is_deleted 标志并相应地编写代码，但这是一个泛型类，所以我不想强制开发人员每次都编写连接，如果我可以在数据库中配置该逻辑。

我希望我的情况/问题很清楚，如果需要，请让我澄清任何要点。

Answer 1

您的第三个选择是设置合理的备份和保留计划，并使用级联删除。虽然我理解“永不删除任何内容”的愿望，但遵守这一原则会迫使您在编程选择中变得多余(选项 1)，或者弄清楚如何构建垃圾表来冗余存储信息(选项 2；您愿意吗？使用数据的字符串表示形式构建一个表，或者您是否制作架构的垃圾副本？)。这两个选择似乎需要大量维护工作(从长远来看)。

我已经使用过这两种选择的变体，如果这些是桌面上唯一的选项，那么选项 1 更容易维护；但是，您必须非常勤奋地使用它，并且必须确保 future 的开发工作达到相同的标准。