草稿/直播内容系统数据库设计

Question

我一直在从事一个需要草稿/实时版本内容的项目，并想到了如下设计：

Article
    ID
    Creator
    CreationDate
    DraftContent(fk to ArticleContent)
    PublicContent(fk to ArticleContent)
    IsPendingApproval

ArticleContent
    Title
    Body

我想知道在发布文章时更改外键是否会更好，或者是否更好只需将草稿表中的内容复制到实时表中即可。

有什么建议吗？

编辑：草稿版本和实时版本同时存在，尽管实时版本是唯一对公众可见的版本。只能有一份草稿和一张直播表，

这种设计的部分原因是为了强制用户的文章在上线之前获得批准。

更新：

我们决定使用 Kieren 的解决方案并稍作修改。我们决定使用单个状态列，而不是对 IsPublished IsLive 之类的项目使用列。除此之外，设计保持不变。

Answer 1

草稿文章开始生效，然后“发布”

通常的情况是在文章表上有一个状态/类型标志 - IsLive。

使用单独的表是不必要且多余的；更改外键也没有多大意义。将文章视为有效对象，无论是草稿还是实时。唯一的区别是，在大多数情况下，您只想显示实时文章。在将来的某些情况下，您可能希望同时显示两者。

最初发布后可能会被编辑并具有新草稿版本的文章

就一篇文章而言，同时具有实时版本和草稿版本 - 最常见的模式是拥有主文章< /code> 实体/对象，然后说来自该实体/对象的 ArticleVersion 。 ArticleVersion 将具有 IsLive 属性，或者更好的是，Article 本身将具有一个属性 CurrentLiveVersionId。这样就可以存在实时版本和草稿版本，但您通常只需通过 CurrentLiveVersionId 将 Article 加入到 ArticleVersion 即可获得当前的现场版本。

使用 ArticleVersion 表的优点包括可以存储文章的整个历史记录（更改日志），因此您可以根据需要恢复到以前的版本，或查看更改。所有这些都是为了非常低的实施成本。

如果我可以澄清这个方法，请告诉我。

Answer 2

你的设计看起来很适合我。当新版本上线时，我会：

1. UPDATE PublicContent 键指向（以前的）草稿文章。

2. 删除不再引用的以前发布的文章。

3. NULL DraftContent 键，或者，如果您的模型要求始终拥有草稿版本，INSERT 将新的空草稿插入 ArticleContent 并将 DraftContent 键指向它。