ruby-on-rails - 处理标记为 "final"的数据与可能发生更改的数据的最高效代码方式

Question

我有几个模型，它们的记录和关联可以有两个必须持久化的状态。最终和草稿。

这里有更多细节:如果模型是“申请表”并且用户提交了最终申请表，那么我需要存储并能够检索该最终申请表。

如果以后用户想要修改该“申请表”，则他们需要编辑该最终记录的草稿副本，直到他提交新的最终版本。也就是说，在选中“最终”框之前，他无法编辑之前的最终申请表，此时草稿成为新的最终版本。

要注意的是，终稿和草稿都有关联，必须与其相关记录一起存储。也就是说，他们的相关记录(例如，应用程序有很多联系人)必须以可从最终版本和草稿版本中检索的方式存储，而不会混淆“最终”联系人和“草稿”联系人。

目前我能想到两种方法来解决这个问题:

• 使用 ActsAsAudited 并仅审核最终记录。每当我需要时查询决赛。 (有一个 ActsAsAudited 的分支也可以跟踪关联)。然后查询审计表以获取最新记录。
• 使用两个并行数据表集:一个保留草稿，另一个仅保留最终副本。

我认为将决赛和选秀放在同一个表格中可能会重复这些表格的目的，并使结构更难以遵循。

您是否知道可以更优雅地处理问题的任何其他架构或策略？或者这会降低代码的复杂性？

这是一个类似的问题，最终使用了上面的第二个选项:

Draft version of database table

伯尼

Answer 1

The catch is that both the final and draft have associations that must be kept in sync

最终版本如何改变？最终版本应该是不可变的。

您的意思是有人可能会在其他用户正在起草的同时起草并提交文档？

如果是这样，源代码控制似乎适用。用于合并文档的 wiki 方法或简单的“锁定”原则会很有用，这样两个用户就不会发生冲突。

对于版本化文档的存储，如果不使用文件系统而想使用常规数据库，主要有两种方式:

1. 将所有内容放在一个表中，并带有 draft|final 标记和“head”标记 - 每个文档的最新最终版本

2. 三张表:一张“首脑”表、一张单独的草稿表和一张包含历史最终版本的第三张表

如果系统变得非常大，那么一种方法相对于另一种方法的优势在于性能和分布。

但如果系统很小，我会提倡第一种方法 - 单个表 - 可能具有三个“ View ”的技巧，以便在 2.0 版中迁移到更复杂的三表方法时不那么痛苦。