2011-04-23 51 views
0

我寧願讓Mercurial爲我保存更改並保留更改,而不是使用SQL Server Posts表和平臺文件(文本/ HTML)用戶內容版本匹配的PostRevisions表跟蹤每個用戶的文件存儲庫的位置。Mercurial作爲版本化數據存儲

這將使備份非常容易,具體取決於您想要如何分享或分片內容。顯而易見的解決方案是擁有一個存儲所有用戶數據的存儲庫,併爲每個用戶ID提供文件夾。

但是,在將文件提交到存儲數百萬用戶文件的存儲庫時,我對此方法的性能和併發性問題感到不好。

有沒有人試圖使用Mercurial作爲平面用戶文件的輔助數據存儲?

+0

你想要什麼版本?內容管理系統的內容?也許實際使用CMS會更明智。 – 2011-04-23 17:55:34

+0

@Erno,我正在嘗試爲我的用戶版本HTML片段。 – 2011-04-23 17:57:24

+0

你是什麼意思的HTML片段?真的,這聽起來像一個CMS的工作。存儲並不昂貴,所以你需要有大量的版本和大量的用戶來使你所建議的方法值得付出。你有任何號碼? – 2011-04-23 18:17:41

回答

1

除非你打算利用更強大的功能,像hg offer這樣的SCM系統,否則我建議你不要採用這種方法。你打算使用分支和合並?可能不會。那麼在這裏使用hg你真的獲得了什麼?備份與數據庫一樣簡單。

在這一天結束的時候,一個包含posts和revisions表的RDBMS工作得很好,並且比基本上基於文件鎖定的解決方案(hg,git等)構建更強大。它也可能會表現得更好一些。

順便說一句,你還應該評估面向文檔的商店,如Mongo或CouchDB。

+0

感謝您的反饋。我對分支,合併和高效存儲感興趣。變化往往是高度遞增的,並且爲了稍後再次比較而存儲整個文檔,看起來像是浪費。 – 2011-04-23 18:09:51

+1

儘管hg/git似乎在合併內容方面做得如此出色,但請記住,您仍然必須開發自己的衝突解決邏輯和UI。這並不簡單。所以這些功能實際上並不是免費的。你必須通過查看差異來解析任何衝突,然後找出用戶的衝突解決方案用戶界面,這並不像並行的差異/合併工具那樣令人畏懼。我不知道......還是不要認爲這與hg相比,會比使用數據庫更少。 – 2011-04-23 18:23:08

+1

還記得SCM系統對於開發者來說是一個複雜的概念,更不用說用戶了。您確定您的應用程序是以足夠簡單的方式向用戶傳達分支/合併和衝突的概念嗎?如果我是你,我會試圖找到一個現成的客戶端庫來解決文檔合併的問題。沒有100%的服務器端解決方案。我也不認爲存儲整個文檔是浪費。您可能需要緩存它以便快速檢索,所以我不會從這種方式進行優化開始。 – 2011-04-23 18:27:14

相關問題