@_@

在生产环境人工操作，楼主很有勇气。

#2 楼 @Rei 数据库会有脚本吧，生产环境不是可以跑脚本么？

简单的字段修改，人工操作是可以的吧。

#3 楼 @chenge 如果写脚本的话，migration 就是 Rails 程序员成熟通用的语言。

人工操作，出了问题就不好解释了，谁也不知道你当时操作了什么。

我庆幸我学 Rails 的时候是一张白纸，所有 Rails 提供的我都接受了，然后再思考我需要的是什么。

对于 lz 的想法，我想我只能呵呵了。

#4 楼 @Rei 这个倒是在理。

不过一两个人的小项目根本不需要这个。完全可以把这个从课程里拿掉，省了不少篇幅。

#7 楼 @chenge 我现在自己弄的项目用的是 Mongodb，没有 migration 这套东西，数据量小有时就备份一下然后控制台操作了。不过这是很不安全的做法，以后还是要找个 mongoid_migration 之类的东西做数据迁移。

Rails 就是大量 Web 开发的经验总结，如果一股脑全接受的话其实还是挺友好的。

之前一份工作由于 migration 和 schema 没注意维护一致性，新人加进来搭建开发环境没一天都不行，跑通之后就不敢动了只做自己负责的部分。

#9 楼 @Rei 数据库本身有 sql 脚本，完全可以做版本控制的。

我说这个的主要目的是减轻 rails 的学习负担，便于推广。ruby 的特点是快乐，快乐是与难度成反比的。

#10 楼 @chenge 所以你预设前提是学习者已经懂得管理关系数据库了，我学习的时候虽然学过一些 SQL 知识，但是管理还是外行，所以 Ruby DSL 对我很友好。

我现在要在 MySQL 终端操作的话还是要看着官方文档对着敲，所以我都优先用 migration，console，性能成问题才用 SQL script。

#11 楼 @Rei 学习者的背景不太一样。应该加一个前提，如果你熟悉数据库的话。

有带菜单的交互工具，操作都有提示，几乎不需要记忆什么。

#12 楼 @chenge 我个人的感觉 migration 是为了迭代而用的 虽然数据库也可以有脚本能完成 但是能放在 rails 里 何乐而不为呢

@chenge 你不爱用 migration 可以用 datamapper 代替 activerecord, migration 和交互工具都不需要了。

只是数据库的演化往往不是简单的把 sql 放版本控制就能搞定的。等到你以后碰到实际问题，自己重造出一套 migration 工具后，就会理解为什么有 migration. 等你 migration 写多了，就会理解为什么要专门为此设计一套 dsl...

#13 楼 @zj0713001 你可以对比下，用交互菜单工具和自己写 t.string，int 还是 integer？哪个容易些？

其实谈 Quick and dirty 的话，用 Ruby 不如用 PHP

migration 这么好用的 DSL，难道不比直接写 sql 简单很多吗，构建这个省心省力的好工具就是为了从繁琐的 sql 语句中解脱，加上多人协作时同步数据库操作，不然你改了数据库的某个表，某个字段别人不知道咋办

@chenge 并行开发的话，用 migrate 只要维护一套程序代码就好了，如果用 SQL 脚本，还要去再做一套维护，何其麻烦，还容易混乱，我学 rails 时候倒没觉得在 migrate 上卡过，这不至于成为学习门槛吧，至于快乐和难度成反比。。。。。那极端快乐不就是植物人了么，完全无脑了

As a complete newbie I have to say that migration is so much better and easier than raw SQL. I won't comment on GUI SQL tools. They are not for developers.

@chenge 最关键的是，当你左手 sql server ,右手 oracle 的时候，你就会感觉到 migrate 何其省心省力啊

#19 楼 @blacktulip 我觉得要区分大项目和小项目，严格和不那么严格的项目。

小项目完全可以用 GUI。

如果你是开发的导弹项目，那是需要小心点。如果只是写个博客就没必要了。

#20 楼 @NonTwitter 遗憾的是 GUI 三分钟就学会了。

@chenge 你错了啊，oracle 的高级应用都基本都是命令行的，三分钟学会的不过就是建个表而已

#15 楼 @chenge 自己写 migration 容易些 数据库不能随便改结构的 如果一个团队 5 6 个人 每个人都改 你自己本地怎么同步呢

#23 楼 @NonTwitter 没听说过 navicat 么，什么数据库都支持吧。

#15 楼 @chenge 如果你就打算写一个 migration 文件的话 那还是用 GUI 吧 时间成本相仿 我现在的商业项目 800 多个 migration 文件 你觉得你怎么写 GUI...

#26 楼 @zj0713001 如果是你自己的项目，一开始就用 GUI，哪来的 800 个文件。

如果是多人，前面有讨论。可以取舍。

@zj0713001 很多时候写 rspec 也要 migration 的

@chenge 数据库直接操作还一点不好就是不方便 rollback

@chenge 如果通过 SQL 脚本实现 rollback，又和 migrate 有什么区别呢，只会更麻烦而已

#24 楼 @zj0713001 多人的话，数据库可以是共用的，不存在同步问题。

产品上线的时候竟然是用工具操作而不是写 sql 脚本的？太狠了吧…… 说得不客气点，无意冒犯 不能因为你觉得不好用，就代表这个没用……

使用 migration 可以帮你很轻松解决以下问题

• 多人协作开发项目时数据库操作的同步
• 跨数据库操作，migration 是数据库无关的
• 初始化数据库，比如说在本地搭建一个别人的项目
• 数据库回滚操作，比如说退回到 n 个改动前的数据库
• 各种操作简便快捷，语句言简意赅

这些都不是命令行，交互工具能实现的

@chenge migration 是非常好的方法， 1.可以对 migration 进行版本管理 2.自动判断哪些 migration 脚本执行过，哪些没执行，没执行的按顺序执行，用脚本不好控制顺序 3.部署在多个地方的时候很方便，每个人有自己的开发数据库，测试组有测试用的多个数据库，产品数据库都能执行，否则每次人工找哪些脚本没执行过非常累 4.migration 可以执行 ruby 代码，可以调用 model 中的方法，这样一些修复数据的逻辑可以既作为维护工具，也可以在 migration 中调用，对新增加的字段特别重要 。。。好处太多了，现在看一个框架首先看有没有好的 migration 方案

就我的项目而言，真不知道没有 mgiration 我会怎么活。曾经想换个框架，但一想到没有 migration 这个东西，顿时没有了躁动。 mingration 有那些作用呢？ 1.你有三个开发人员，如果数据库里要增加一个列，你需要用 gui 工具做三次，每个人要做的一样。当代码测试好，你要发布代码的时候，你还要用 gui 改一次。如果两天之内改了两个列，涉及三张表，部署生产环境的如果不是你，请问你安排谁来做？ 2.数据库里已经有数据了，新修改了一些列的定义后，要做数据的清洗，还是三个开发人，每个人的测试数库都有些小变化，你怎么去给三个人更新他们的测试数据。另外，原来有一列是用 md 加密的数据，新算法换成 sha1 了，你用 sql 怎么做数据转换？

#33 楼 @diudiutang 总结的好

#28 楼 @NonTwitter 照楼主的意思 你觉得他会写测试么...

@zj0713001 其实说到这，我突然想 rails 对存储过程啥的数据库高级应用，支持怎么样呢，自从转行做 rails 貌似再也没碰过

#38 楼 @NonTwitter 太惭愧了 转 rails 以后我也没用过...

#37 楼 @zj0713001 测试太难学／太麻烦，影响 rails 的推广，还是去掉吧 - According to 楼主

数据备份保证安全，万一出错可以恢复。

我们的做法两个人共用一个数据库，开发==部署，当然不会有大的修改。

#37 楼 @zj0713001 目前只有操作测试，没别的 spec 测试。

我一再说要看项目的情况。

#40 楼 @blacktulip 能看见你用简体中文回复 感动的要哭了

#40 楼 @blacktulip 这些可以作为选修。

migration 可以 commit 到版本库，可以保证 db:migrate 之后的结果是一致的，这是多么舒服的一种情况啊。

在开发中好处和效果都很明显，就算是几个人的小团队，我加了一列，还要给你讲一下，你自己再开个图形界面工具自己再加一列，万一一个人这两天休假了，过两天回来了，他要在 5 个表里删 8 列加 7 列，实在不行只能再导出一份.sql 导进去，这时候可能他休假前加的两列就没了...这简直是...hell, never want to go back to that again.

@chenge 确实，我也是最后学的测试

#41 楼 @chenge 这个... 我还是觉得用代码写的更明白... 唉... 我就有一个 GUI 工具 还从来不用... 项目很小的话 这个争论其实没意义 主要还是对大项目有用

@zj0713001 GUI 工具我都有，但是一般不用，因为长时间不用都不会用了，用也是打开命令行面板写代码，主要是长时间不用，基本不会用了，还有很重要一点就是，GUI 没法 google 出解决方案啊，命令行的好找多了

@chenge 萝卜白菜各有所爱，存在即合理，如果楼主觉得 GUI 好用，就继续用 GUI 挺好的，等到真正觉得需要用 migration 的时候再用也可以，没有必要为了一个工具而用一个工具，用适合自己的。

#14 楼 @luikore 其实我还是觉得 SQL 比各种 DSL/ORM 好写多了.....如果能MyModel = load("table_of_my_model.sql")就好了

楼主给你们挖坑，你们还真往里跳...

几年前有人在 phpchina 上挖了个 ORM 的坑，到现在那帮人还在跳。

#50 楼 @ch3n 哈哈 顶

lz 这样比较适合小项目，真正的线上生产环境，migration 是很有必要的，特别是在多次迭代的时候，数据库的变化也是需要控制和追踪起来的，migration 做的正式这些事情。

楼主肯定没有真刀真枪的玩过 我们项目几年内对数据库的修改达到上千次 没有 migration 的结果就是你不知道别人修改了数据库，当然别人也不会通知你，直到出错以后才找一个勉强能解决问题的数据库脚本跑一跑，如果没出错就不跑了。经过几个月几年的时间和正式数据库的差距越来越大，最后发现出了问题跑脚本也是错误一大堆，才会意识到当中其实漏跑过很多脚本了。但是由于时间长久，记不清了，因此这个库最终无法修复了。这就是没有 migration 的结果。。。

#53 楼 @iBachue 如果多人共享数据库，就不存在同步问题。

还有原理问题，它是依赖文件名上的时间吧，如果多人的机器时间不一致，会有问题吗？ 另外，各位会用到 rollback 吗，人工写 rollback 工作量不大么？

我觉得它肯定是有用的，但不是每个项目都必须的。

migration 就是需要它的时候，它绝对有用武之力。

你不需要它的时候，它一无是处。

@chenge 默认的 rollback 就很强了

#56 楼 @NonTwitter 默认是什么意思，我记得要人工写反向操作，什么 up，down。

@chenge 你没用过 change 么

#57 楼 @chenge 大部分操作现在可以自动了

def change
   add_column :xxx
end

程序可以推断出 rollback 就是 remove_column

#58 楼 @NonTwitter 我知道新版改成了 change，是不是不需要人工写反向操作，有那么智能么？

@chenge 你去试试不就知道了么。。。。

#54 楼 @chenge 没人喜欢共享数据库的。万一别人搞出了问题怎么办，数据库版本和当前代码 branch 不匹配怎么办。 还有 默认用得是 UTC 时间 出问题的概率太低了（即使时间有点偏差也不会引发什么问题）。。 至于 Rollback 脚本 其实一直以来都是必需品啊，无论是不是用 migration。你不给出 Rollback 方案你以为 DBA 会放你过门嘛

#49 楼 @bhuztez 这个想法不错，顶一个

当时用 Yii，三个人的小玩意儿，你不知道没有 Migration 是多么的痛苦，还好后来 Yii 也有这玩意儿了……

#35 楼 @jimrokliu 原来有一列是用md加密的数据，新算法换成sha1了，你用sql怎么做数据转换？

我也有同样问题，请问你是怎么转换的？

#65 楼 @Peter 这个需要用户的密码明文，应该是做不了。我举例不恰当，应该时想说明有些方法不是 sql 的函数，不能直接些 sql 实现。

#54 楼 @chenge

还有原理问题，它是依赖文件名上的时间吧，如果多人的机器时间不一致，会有问题吗？

你不知道依赖时间戳的作用是什么？本来要的就是不一样，时间戳就是为了避免产生同名不同源的 migration 产生，不一样就对了。当然，你可以反过来说“难道就能保证不出现一样的？”，那我就没啥可说的了，没人可以保证任何事情，Migration 不算完美无缺，但是它一直在进步，所有现在觉得理所当然的事情在一开始都会被人质疑，能够阻挡它前进的既不是你，也不是我们之中的任何人，只有它自己。

#67 楼 @nightire 我是说是否有前后顺序的问题。

#68 楼 @chenge 呵呵，不多解释了，奉劝您还是多了解了解 Rails 里的 Migration 吧。这就好像打仗，知己知彼才能百战不殆。

@chenge 您真顽强，一个人对抗整个论坛。。。。。

migrate 最大的好处就是用统一的规范，低成本（对开发人员来说，低成本就是便利）地让各个环境（生产、测试、开发、个人）的数据库达到一致。 没有它之前，每个环境的人都得去检查是否有人更新数据库了，如果有，就复制粘贴执行，再打上自己的标志，这么多步骤难道不复杂吗？比起记一个命令真的是复杂麻烦多了。 至于楼主觉得 dsl 有一定的学习曲线，增加学 rails 的难度，那可以直接把原生的 sql 复制到 migration 脚本中，使用 migrate 执行即可，这样即可以不用让人去学习 dsl，又可以用上 migrate 的好处。 不用 dsl，我认为在多数项目中都是可行的，毕竟有几个项目会在中途更换数据库呢？