我已经做了类似的事情最近,走近它作为一个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