我已經做了類似的事情最近,走近它作爲一個3步驟的過程。可能會有更多Rails的方式來做到這一點,但這種方式對我而言並沒有什麼意義。
我使用了一種迭代方法,並利用了MongoDB實際上是一個非常關係友好的文檔存儲系統。我從一個使用Mongoid的Relational Associations(頁面底部)references_many和referenced_in語法的關係設置開始。一旦工作正常,我將迭代重構爲更多面向文檔的方法。
1.轉儲現有的數據庫直MongoDB的
我用現有的模式,以蠻力轉儲SQL表和數據轉換成並行MongoDB的文件。我只是猛烈抨擊了我所擁有的一切,而不用擔心命名或關係;表格與集合的嚴格1:1映射。
這對我來說是一次性的過程。一旦所有事情都在這裏,步驟2和步驟3就將這些數據轉化爲我想要的結構。我也可以改變我的模型,因爲我不再需要與關係系統進行交互。您可能希望創建某種現有模型的副本,以防因任何原因需要返回此步驟。
2.遷移數據
對於下一步我有一個自定義的紅寶石外殼程序去了。再次說明,使用Rails功能可能會有更好的方式來完成此任務,但我採用了直接的事務腳本樣式方法。
我使用原始MongoDB Ruby driver,讀取在第1步中創建的數據庫,並將源集合轉換爲我想要的形狀。我用在步驟1中創建一個目標一個單獨的數據庫,因爲我反覆修正這個腳本變得越來越面向文檔的,因爲我重構我的模型在第3步
3.重構模型需要
我重構了我的模型,以便在步驟2中創建的數據庫上運行,使測試通過,然後返回步驟2中的腳本並進行更改以使數據庫更加面向文檔。
我重複了第2步和第3步,直到我重構了我的模型和文檔佈局,直到獲得最終結果。
來源
2011-03-17 15:06:16
blu
爲什麼要切換? – 2011-03-17 11:29:20
1.看起來像我的數據更合適文件意識形態; 2.教育理由; 3.這個項目對數據安全並不重要,所以我可以做這個實驗 – fl00r 2011-03-17 11:32:10