數據庫中的兩階段數據編輯

爲了這個問題的目的，我們假設我有一個博客應用程序，它由與博客相關的博客和博客子條目組成。我的數據存儲在兩個單獨的表中的數據庫中：Blog和BlobSubEntries，並且在Blog上的BlogSubEntries中有一個外鍵。這兩個表都包含可以編輯的數據。數據庫中的兩階段數據編輯

現在我的網站查詢這個數據庫來顯示博客。我也有一個cms來編輯博客條目。我不想在cms中放置一個保存按鈕，所以我想發送每一個編輯到服務器，但不希望這些數據在博客實際決定發佈作品之前提供給網站。

這裏有一些事情要考慮：

我不想有上百萬查詢的數據庫。
我希望舊數據在編輯期間可用。
我使用Django的關係數據庫

這個漫長的介紹後，這裏是我的問題：

你將如何處理數據的這兩步分期（考慮的是，有兩個模型相互關聯）？
如果我想將這個暫存過程演化爲版本化，該怎麼辦？
我最近讀了一些關於CouchDB的問題，文檔數據庫能夠簡化這種問題嗎？如果是這樣如何？

謝謝你的時間。

來源

2011-02-11 Eric Fortin

一個快速的回答將是有像模特：

[Blog]<-----[BlogSubEntries]<----[SubEntryDraft] 
^  (current content) |-------------| 
    |        |draft_content| 
    |        |-------------| 
[BlogDraft] 
(draft content)

如果你想要做的版本，那麼你會碰到這樣的：

[entry]-(1)-------(N)-[entry_version] 
         |-------------| 
         | version_num | 
         | content  | 
         |-------------|

我不認爲一個文件存儲引擎會有很大的不同。您仍然需要跟蹤哪個版本的內容屬於給定條目（或博客，或其他）。當然，除非你使用的系統已經提供了版本控制。

現在我想想，你也可以做一個單一的表：

[ BlogSubEntry ] 
|----------------| 
| content  | 
| entry_id  | <--| composite alternate key: 
| version_num | | UNIQUE(entry_id, version_num) NOT NULL 
| surrogate_key | <-- PRIMARY KEY 
|----------------|

來源

2011-02-11 12:53:09 Rafa

數據庫中的兩階段數據編輯

回答

相關問題