新手问题 数据库已经有了，如何重写成 Rails 应用
2018 年 3 月 22 日，结贴
感谢各位的指点，受教良多：
- 如果只是想锻炼技术，有很多方式;
- 现有系统运行稳定，若想替换，再三考虑，特别是生产事故;
- 数据量如果较大，建议用更直接的方式进行迁移，免去不必要的开支;
huacnlee：要大量迁移，得写成并发执行（Ruby 也写成可以并发执行的），最好是批量原生 SQL 插入，避免无谓的动作降低速度
2018 年 3 月 18 日
我现在有这么一个 场景： 原先的系统已经运行了一段时间，期间已经产生了许多的数据。现在我准备把以前的系统，改成 Rails 的。那要怎么利用上原来的数据呢？
我感觉，主要的 思路 就是：
- Rails 中新建迁移，把表结构和模型处理好。
- Rails 中把原始数据通过迁移的方式导入进去，（或者使用数据库还原工具）
- 正常使用原始数据...
如果数据库体量比较大（60G），表的数目比较多（300 张），那要一个个添加上这些还是挺困难的。
我翻看 Rails Guide Active Record 迁移章节，提到了 数据库模式转储.。
不知道数据库模式文件，到底怎么用？
重新创建了数据库结构，就继续在 Rails 中创建模型吗……
重写系统可能会历时半年，期间一点产出都没有，失败风险很大，要考虑清楚是否要这么做。
如果系统可以短暂停机，并且不需要对老接口兼容，那么可以写个全新的然后写脚本把数据搬运过来过来。考虑到数据量大，可能要用 SQL 做。
如果系统不能停机，需要对老接口兼容，那么就复杂了，可能要做双向数据同步，看到一篇文章挺好的，但我没实践过 https://blog.heroku.com/monolithic-applications-into-services
同意 5 楼的 如果是重写的话没有必要迁移数据库，使用旧的数据库，创建对应的 model，ActiveRecord 会自动对应表里的字段。可以参考 https://stackoverflow.com/a/29571368/8493113
Rei
嗯嗯，感谢您的回复。目前我也还只停留在“想法”阶段，距离“行动”还得再精打细算一番。我之所以有这样的打算，一方面想锻炼一下自己的技术，一方面也是想以后的维护不那么痛苦。哈哈，在探索的过程中，就会有很多想法啊。
BigNerdCoding
原有的旧系统，维护过程就像是在不断地堆垃圾，实在难以忍受，才会有此想法。不过，也确实是想尝试新语言新框架，毕竟 web 要涉及的东西对我来说还是太多，换种语言换种思路，或许会带来新的拓展。
在维护老代码的时候想整个推翻重来，这是程序员的常见病，得治 
老代码久经考验，很多人补过无数坑，不是一个脑袋短期内能考虑周全的。
如果想锻炼一下技术，可以试着用 Rails 套上 discuz 的表重写一下，这对推广 Rails 应该很有帮助，还避免了老系统崩溃的问题。
如果准备重写的话，可以考虑在 Rails 这端设计新的数据库结构，然后实现 sync 机制把新数据同步到老系统的数据库里，直到新系统完全取代旧的
我也是新手..我提供一个方案。
我最近自己在做一个爬虫和 rails 结合的项目，爬虫数据存储到数据库，然后 rails 连接同一个数据库。 由于我这个项目的数据部分只需要从数据库读取。第一步是建立对应的 model，新建 model 的时候没有新建 migration 文件，然后在 model 中使用 self.table_name = "" 的方式，迁移一下，scheme 文件中就可以看到对应的字段了。（爬虫的数据库是 pg rails 数据库也是 pg）
数据部分就搞定了，剩下的如果新建 model 就和平时写 rails 没什么区别了。
顺便再提供几个我考虑过的方案。一是导出 csv 再导入，二是直接数据库导出 sql 然后导入。第二个方案如果数据库不同的话需要做一部分修改。
因为我也是才开始写 rails 没多久，这有几个我参考的 ruby china 中的帖子，希望对你有帮助！
你 60G 的数据，有多少条记录？
你要考虑下面的问题：
- 有没有老的 API 什么的需要向下兼容的？
- 有没有足够的人一起干这个事情？
- 如果有老功能，老 API 需要兼容，是否有测试团队帮你验证？
- 有没有足够能力确保新做一次，比之前好很多，让老板支持？因为这个周期比较长。
- 等你开发完升级上线的时候，需要做数据迁移，你有没有能力在不停机，或短时间停机快速迁移完成？
关于老数据迁移
反正这种大量数据（上百万条）迁移，你要想当然的用 Rails 来写，走 ActiveRecord 的流程是很慢的（因为有各种验证、Callback ... 等等和迁移无关的动作），不适合大量迁移。
要大量迁移，得写成并发执行（Ruby 也写成可以并发执行的），最好是批量原生 SQL 插入，避免无谓的动作降低速度。
量更大的时候，你可能需要分布式，例如 (Hadoop 集群）的方式来执行迁移动作，不仅是并发，还多机器并发。
你还得考虑迁移过程中断（例如开发环境验证没遇到的奇怪数据）以后能增量迁移的问题，这样可以在升级前先把存量的老数据前迁移到新的库里面。等到最终测试完成，要上线的时候再增量跑一次后面新增的少量数据（这样能减少停机时间），完成以后一次切换掉。
Peter
是的，不能总想着推翻旧系统，哈哈。Rails 有许多应用的方式，我换个途径锻炼之。但仍然保留以后重写系统的想法，感谢指点。
huacnlee
最大的表也就在百万级别…
- 有老的 API 要向下兼容;
- 人力总是紧张的;
- 测试 case 要重新写，没有专门的团队;
- 信心是有，就怕太过理想，总体衡量下还是有点悬;
- 并非 24 小时不间断的系统。
再三思索了下，主要的业务系统不太好重写。倒是可以给原有系统增加一些功能分支，逐步引入 rails。也感谢您的指点 
