草案/直播內容系統數據庫的設計

我一直在做一個項目，需要的草案內容/現場版，並想到了設計，如下面：草案/直播內容系統數據庫的設計

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

ArticleContent 
    Title 
    Body

我想知道如果這將是最好在發佈文章時更改外鍵，或者更好地將草稿表中的內容複製到活動表中。

有什麼建議嗎？

編輯：草稿版本和實時版本同時存在，但實時版本是唯一一個公衆可見的版本。只能有一個草案和一個現場表

這個設計的部分原因是強制用戶在他們上線前批准他們的文章。

更新：

我們決定稍微修改Kieren的解決方案。我們決定使用單個狀態列，而不是像IsPublished IsLive這樣的項目使用列。否則，設計保持不變。這成爲活，然後文章

來源

2011-10-25 Walt Weidner

草稿「發佈」

通常的事情將是對文章表中的狀態/類型標誌 - IsLive。

使用單獨的表格是不必要的和多餘的;改變外鍵也沒有多大意義。把文章想象成一個有效的對象，無論是草稿還是生活。唯一的區別是，在大多數的情況下您只想顯示直播文章。在將來的某些情況下，您可能想要同時顯示兩者。可能被編輯後最初成爲活

，在帶有活和草案的版本一文方面有一個新的草案版本

文章 - 最常見的模式將有一個主Article實體/ object，然後說ArticleVersion來自那個。 ArticleVersion將具有IsLive屬性，或者甚至更好，Article本身將具有屬性CurrentLiveVersionId。這樣，可以有直播和草案版本躺在身邊，但你通常只加入Article到ArticleVersion由CurrentLiveVersionId得到當前動態版本。具有ArticleVersion表

優點包括文章，更新日誌，整個歷史可以存儲，這樣你就可以恢復到如果需要以前的版本，或檢查變更的事實。所有非常低實施成本..

讓我知道如果我可以澄清這種方法。

來源

2011-10-25 21:28:02

+1，「具有獨立內容表的文章單表」實際上是在這裏飛行的方式。 –

可能非常簡單 - 每個ArticleVersion都有一個ApprovedBy/ApprovedDate，如果它是空的（在業務邏輯中）它不能被設置爲當前版本？ –

而不是有一個版本號會不會更好地做版本行的修訂日期和創建日期？這樣，用戶可以修改草稿直到太陽下山，並且在網頁發佈時僅顯示不同的版本？ –

您的設計看起來適合我。當一個新版本的上線，我想：

UPDATE的PublicContent鍵指向（原）條草案。
DELETE該不再引用的以前發表的文章。
NULL的DraftContent鍵，或者，如果你的模式要求有一個草案版本，INSERT一個新的空草案進入ArticleContent，並指出了DraftContent鑰匙。總是。

來源

2011-10-25 21:31:33

草案/直播內容系統數據庫的設計

回答

相關問題