我們正在構建一個web應用程序，作爲debian軟件包提供給多個客戶端。每個客戶運行他自己的服務器。但更新和支持是由我們完成的。 我們使用乾淨的版本號定期發佈產品。大多數用戶獲得自動更新（通過Puppet），其他一些用戶則沒有。Web應用程序：跟蹤數據庫中應用程序的版本？
我們要保持的應用程序的版本痕跡（以允許用戶在「關於」一節中檢查版本，以及對我們的支持，以幫助用戶更準確）。
我們打算存儲的代碼，並在我們的數據庫中的基礎版本的版本，並自動保持信息是最新的。
這是個好主意嗎？
我們看到的另一種選擇是文件。
編輯：代碼和數據庫模式一起更新。 （如果我們更新到版本X.Y.Z，代碼和數據庫去X.Y.Z）
使用表來跟蹤每一個變化，以作爲this post描述的模式是一個很好的做法，我肯定會建議遵循。我想在包中嵌入一個文件（因此不使用數據庫來存儲Web應用程序的版本），對於應用程序，如果它獨立於數據庫發貨（這對我來說不是很清楚） 。
如果沒有，因此如果這兩個應用程序和數據庫版本保持同步，那麼我只希望使用存儲在數據庫中的信息。
假設沒有令人信服的理由去用一種方法或其他的，我想我會跟他們留在該數據庫中去。
作爲一般規則，我會同時擁有數據庫版本和應用程序版本。這裏的問題是數據庫是如何「私密」的。如果數據庫對應用程序是「私有的」，並且用戶永遠不修改架構，那麼您的初始解決方案就沒有問題。根據我的經驗，積累多年數據的數據庫不再是私有的，這意味着用戶使用一些報告工具添加一兩個表並訪問數據;從那時起數據庫不再被應用程序專用。
UPDATE
一個更多的考慮的是用戶（應用程序）不能夠連接到數據庫，並呼籲支持。對於這種情況，最好是有版本等等。存儲在文件系統上。
我會把它們放在兩個地方。然後，在運行about功能時，您可以快速檢查它們是否相同，如果不是，則可以顯示有關版本不匹配的額外信息。如果它們是相同的，那麼你只需要顯示其中的一個。
我通常會發現用戶可以通過手動複製目錄不喜歡還原數據庫「聰明」的事情到原來的版本身邊「因爲他們可以」，所以防守對付它始終是一個好主意。
該數據庫是完全私人的。用戶甚至不知道數據庫存在。他不具備謹慎性，也不會擁有它們。 – 2009-12-01 09:02:55