應該將記錄草案保存在單獨的表格中嗎？

Question

我們正在構建一個簡單的基於網絡的系統，通過這個系統，某人添加了一個記錄，例如一個CMS頁面，並在網站上顯示之前由負責人批准。

如果作者隨後決定編輯該頁面，我們希望基於實時副本創建草稿，在批准時它將替換舊的實時頁面。

我們考慮過要完成版本控制，但相信我們可以通過只有1來簡化這個過程。僅僅是一個草稿，2.只是一個活的，或者3.一個草稿，一個活的。

此功能是跨多個「事物」而不僅僅是頁面需要的。

最後問題：你認爲將這兩條記錄存儲在同一張表中還是鏡像表更好會更好？

我想這可能取決於，但我不喜歡具有相同結構的兩個表的理想。對於稍微慢一點的操作（因爲我們必須在顯示數據時始終查詢草稿）是否值得呢？

Answer 1

第一個實體類型，一個表。

理由重新考慮：

1. 記錄草案由成千上萬的因素多於現場記錄之一。

2. 安全條件要求訪問數據庫的某些用戶直接對GRANT/REVOKE級別的草稿或活動記錄擁有某種權限，但不得超過其他類型的記錄。

的第二個設計考慮是對項目和LiveItems第二表的一個表。第二個表格僅包含活動項目的ID。這樣你就可以維護你的單表設計，但是你可以通過將你的單列表連接回主表來找到LiveItems。

Answer 2

當狀態發生變化時，將東西從表格移動到表格是一個壞主意。

當您想要將其他狀態添加到工作流程時，您必須添加更多表格。

這只是一種狀態變化 - 這就是關係數據庫的優化對象。

一個表，多個狀態是標準方法。

如果您發現事情非常緩慢 - 並且您可以證明基於狀態的查詢是完整的原因 - 您可以訴諸於「物化視圖」或類似的技術狀態改變（以及由此產生的移動）由RDBMS處理。

Table-per-state是一個壞主意。

1. 您不能輕鬆添加狀態。你必須添加表格，並且使它變得很痛苦。此外，您必須使用新的表名更新代碼以反映新的工作流程。

   如果一個狀態只是一個列，那麼添加新的狀態就是在代碼中添加新的值和新的if語句。狀態更改只是更新，而不是「刪除 - 插入」。

   數據永遠存在，每當用戶有一個聰明的想法時，工作流程都會來去去去。不要因爲想改變工作流而懲罰他們。

2. 你不容易有子狀態。許多狀態機實際上是多個嵌套的狀態機。用每個表的狀態添加一個子狀態可以創建更多的規則更多的表。

   如果一個狀態只是一個列，那麼嵌套的子狀態就是代碼中帶有新的if語句的另一列。狀態更改只是更新，而不是「刪除 - 插入」。

3. 你不容易有並行狀態機。很多時候，有許多並行狀態代碼更改。有時會有手動工作流程（審批）和自動化的工作流程（歸檔，複製到數據倉庫等）。）對於每個狀態表和並行狀態機，沒有辦法合理地實現它

   如果每個狀態只是一個列，那麼並行狀態機就是並行更新。

Answer 3

同意上面給出的所有意見：只有一個表。
通過scopes，您可以輕鬆獲取已發佈的帖子或草稿。

我不會爲它推薦。
但是，如果您確實希望草稿和發佈的條目有兩種不同的模型，則還有其他解決方案：STI。

你就會有兩個型號：

class Post < ActiveRecord::Base 
end 

class Draft < Post 
end 

任何對象草案從表後採取的。
Type參數使其成爲帖子或草稿。

每當你要發佈一個帖子你那麼要做的：

@draft = Draft.first 
@draft[:type] = 'Post' 

Answer 4

我剛剛作出了一個寶石這樣的使用情況。它在單獨的表格中存儲草稿： https://github.com/ledermann/drafting