草稿/实时内容系统数据库设计

Question

我一直在研究一个需要草案/实时版本内容的项目,并考虑过如下设计:

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

ArticleContent
    Title
    Body

我想知道在发布文章时更改外键是否更好,或者是否最好只将草稿表中的内容复制到实时表中.

有什么建议？

编辑:草稿和实时版本同时存在,但实时版本是唯一对公众可见的版本.只能有一个草稿和一个实时表格

这种设计的部分原因是迫使用户在上线之前批准他们的文章.

更新:

我们决定稍微修改使用Kieren的解决方案.我们决定使用单个状态列,而不是像IsPublished IsLive这样的项使用列.否则设计保持不变.

Answer 1

生效的条款草案然后被"发布"

通常的做法是在文章表上有一个状态/类型标志 - IsLive.

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

在最初生效后可能编辑并具有新草稿版本的文章

就一篇同时具有实时和草稿版本的文章而言 - 最常见的模式是拥有一个主Article实体/对象,然后说ArticleVersion出来.该ArticleVersion会拥有IsLive财产,甚至更好,则Article本身就具有的属性,CurrentLiveVersionId.这样,可以有直播和草案版本躺在身边,但你通常只加入Article到ArticleVersion由CurrentLiveVersionId获得当前动态版本.

拥有该ArticleVersion表的优点包括可以存储文章的整个历史记录,更改日志,因此您可以根据需要恢复到以前的版本,或者查看更改.所有这些都是非常低的实施成本..

如果我能澄清这种方法,请告诉我.