【问题标题】:Draft / Live Content System Database Design草稿/直播内容系统数据库设计
【发布时间】:2011-10-25 21:19:39
【问题描述】:

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

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

ArticleContent
    Title
    Body

我想知道在发表文章时更改外键是否更好,或者是否将内容从草稿表复制到实时表更好。

有什么建议吗?

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

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

更新:

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

【问题讨论】:

    标签: sql database database-design


    【解决方案1】:

    草稿文章开始发布,然后“发布”

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

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

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

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

    拥有ArticleVersion 表的优点包括可以存储文章的整个历史记录(更改日志),因此您可以在需要时恢复到以前的版本,或查看更改。一切都是为了非常低的实施成本..

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

    【讨论】:

    • +1,“单篇文章,单独目录”真的是飞到这里的路。
    • 可能非常简单 - 每个 ArticleVersion 都会有一个 ApprovedBy / ApprovedDate,如果它为 null(在业务逻辑中)它不能设置为当前版本?
    • 与其有一个版本号,不如为版本行做一个修订日期和创建日期不是更好吗?这样用户就可以在日落之前修改草稿,并且在页面发布时只显示不同的版本?
    • ID 在 RDB 中非常重要。本身没有“版本号”,但我什至认为应该存在。而不是 CurrentLiveVersionId,如果您依赖日期,则可以在每个版本上使用 PublishDate,然后在显示文章时,检索第一个 PublishDate 早于现在已批准的文章(已批准是重要的一点)。
    • 这个设计的问题是你应该如何保持旧草稿笔直?如果主文章表中有指向单个版本记录的外键,是否应该在每个版本中都有指向主文章的外键?
    【解决方案2】:

    您的设计看起来很适合我。当新版本上线时,我会:

    1. UPDATE PublicContent 键指向(以前的)文章草案。

    2. DELETE 不再引用的以前发表的文章。

    3. NULL DraftContent 键,或者,如果您的模型要求始终有一个草稿版本,INSERT 一个新的空草稿到 ArticleContent 并指向 DraftContent关键。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2012-02-12
      • 1970-01-01
      • 1970-01-01
      • 2010-11-10
      • 1970-01-01
      • 2014-10-23
      • 2015-10-26
      • 2020-11-21
      相关资源
      最近更新 更多