Rails Rails 中两个项目用一个数据库
弱弱的问一下，共用数据库我是知道的，能共用 model 嘛？ 就是有两个项目 A, B. 现在在 A 里面创建完整的 MVC，然后在 B 项目里面只创建 VC，使用 A 里面的 M. 有这样用的嘛？或者有什么类似的用法呢？
最好的方法是给 A 的 models 做 API 并设置 localhost 路由，B 通过内部路由访问 A 的 API 进行读写。这样相互独立，可维护，可扩展。
千万不要共用数据库，或用复杂的手法调用 A 的 models。
@iBachue 共用数据库可能比共用 models 的问题只多不少。
问题一：validation
举个例子，假设现在好几个类似 redmine 的 rails app 同时跑在一个数据库上。其中有一个表是 issues，一个 app 要求 issue 必须 50 个字，一个只要求 20 个字。因为是不同 team 在维护 models，这个很可能出现。那么好了，一个 app 写入了 20 个字的 issue, 完全没有问题。另一个 50 字的 app 可以读到这个 issue, 但当用户要修改它时，bingo! invalid! 怎么办？
问题二：数据一致性
假设 app1 的 User model 会有一个 callback, 自动把用户名变成小写并存入。但 app2 没有这个，那么存入数据库的用户名就会有大有小，造成不一致及各种麻烦。
共用数据库的情景下这些问题的唯一解决方法就是 team 之间互相沟通（指责？），但没有任何代码和机制保证不会出问题。
@iBachue 如果大量依靠 SQL 语言来写应用，那真没必要用 Rails 或其他类似框架了，直接 PHP 加一个 template engine 就可以搞定需求了，速度还快。
还有一个情景。假设有个需求变更，需要更改或加减某些 attributes。如果用 API 的话，作为维护 API 的人，我可以轻松做一个 version，或者看实际情况用 ruby 写出向下兼容的 API。但如果是共享数据库呢？谁可以决定？需不需要所有 team members 一起开个会看看怎么改 db?
@iBachue ，我觉得，比较多的场景是有一个项目 A 是先大致成熟的，然后其他项目 B，C，D 等才会考虑共享数据库或 API，根据 A 的情况，大致有以下几种场景：
一、A 是打算不久后被替代的老项目。
这种情况我觉得共享数据库比较合适。A 可以暂停开发，只解决 bugs。开发精力放到新项目。API 也可以滞后甚至不需要。
二、A 是在用的项目，并且期待继续发展。
这种情况我觉得共享数据库就不合适了。而且也不需要立刻设计一套完整的 API 系统才能做新项目。可以根据 B，C 的需求先在 A 里面加上必需的 API 以及内部路由。需要什么就开发什么。等成熟后再考虑是否迁出 A 里面部分或全部的 API，或者不迁也可以。
三、A，B，C 都是新的，同时设计的
这种情况我觉得根据需要可以直接从头开始设计一些独立的服务，比如用户、通知等等。让 A，B，C 等消费。
@ywjno 你把数据库和 API 看成同样的东西就好了啊。MongoLab, 还有 Heroku 里面那些 MongoDB 的服务不都是 API 的形式？