真的有必要需要这种工具？ 你们建模都是为了达到什么目的？

#1 楼 @huacnlee 有时候字段什么的，定义会忘记。更好的梳理关系什么的。Java 那边用习惯了。

#2 楼 @bpw11320 很多 Java 的思路我实在无法理解，ActiveRecord models 里面 belongs_to has_many 的描述已经表现的足够清晰。

我做过涉及 20 多张表的项目，没有存在哪些理不清的问题。

如果你需要一个图表，Ruby 是有那种工具可以基于 Model 机构生成你想要的东西。叫什么我忘了。

试着转换一下思路，你真的用不着那个。

@huacnlee 你指这个 https://github.com/ctran/annotate_models ？

#4 楼 @HungYuHei 不是，有能出图片的

https://github.com/voormedia/rails-erd 是这个吧？ 刚开始进组用 rails 的时候生成过一张 ERD 图，后来发现还是看代码清晰

#3 楼 @huacnlee 有另一种可能性使用建模工具会比较好，就是客户提需求，给你发过来一份不是很专业的需求文档…不提前建模会死的很惨。自己写项目的话，到时不必须用

我们内部使用 MySQLWorkbench

#7 楼 @chunlea

1. 基于文本文档 (Markdown) 设想好需要的基本需要的表、字段、类型；
2. 使用 Rails Migration 随着功能的开发逐步创建表；
3. 随着细节功能的开发、需求，逐步增加字段，删除字段，或者调整字段类型；
4. 第一个 Release 的时候清理 Migrations 合并成一个;
5. 随着后期的改动，逐步增加、修改、删除字段或表。

基本上我的所有项目都是这么搞的，这和项目是否复杂无关。所以我前面为什么说思路需要转变。

你真的需要文档么？！你需要反思你的代码结构是否清晰，注释是否到位。

#9 楼 @huacnlee 同意，不过第一步不就是建模的过程么？区别就是是使用建模软件还是纸笔的问题而已。

#9 楼 @huacnlee 第 4 个过程呢？在没有合并 Migration 的情况下。我现在就是纠结在这个过程中。不停的对表进行操作的过程中（增加或者删除字段），会产生 N 多的 Migration 时间长了对于多个 Migration 的理解怎么弄呢？对于其他人怎么理解，毕竟 Migration 很不直观。

navicat

#11 楼 @bpw11320 发布之前用 schema.rb 的内容作为一个 Migration 文件，其实某些稳定的时候，也可以怎么做的。

RubyMine 可以生成模型关系图

Navicat Data Modeler Essentials 商店里有免费的

#13 楼 @huacnlee 真的不想喷你，看得一群人都笑了，"我做过涉及 20 多张表的项目，没有存在哪些理不清的问题。" 20 多张表，我只想说，"哇，好大的项目"

https://www.navicat.com.cn/products/navicat-data-modeler