我开始使用单个Rails应用程序。非常简单，基本上只读，用于业务线应用程序的前端（使用视图备份以检索数据） - 使用一些标准表来扩充视图。
我现在需要在新应用程序中使用相同的数据集（2个应用程序，虽然共享相同的数据，但工作方式不同，尝试将它们合并到同一个应用程序中并非易事。）
我认为将我可以重用的模型拆分到自己的引擎中并让2个应用程序共享数据库是最容易的。
添加API并让两个应用程序查询都是一个选项，但实际上我不确定我是否可以提供能够正确满足这两个应用程序的API，因为它们以不同的方式使用数据。
在此基础上，我想我是否为每个应用程序提供了一个表前缀，或者使用不同的模式来命名它们 - 这样每个应用程序都有自己不同的表来表示他们不共享的内容，但我可以轻松地重用现有的视图无需复制它们。
除了忘记了常见视图和数据的迁移之外，这两个选项似乎都很有效。
所以我唯一能想到的是：
由于2个应用程序有点紧密耦合，我的公共数据引擎根本没有迁移 - 对视图/表的任何更改都将由“第一个”应用程序处理。这似乎有点讨厌，因为模型现在包含在一个单独的引擎中。 我不喜欢在引擎中进行迁移然后将它们复制到一个或另一个中的想法，因为这基本上是相同的。
我使用pivotal labs建议，但添加一些代码来检测它是否在“第一个”应用程序中，并且仅适用于此。如果我没有做到这一点，我最终会得到两个应用程序，包括引擎迁移，这会导致两个应用程序都尝试运行相同的迁移，并且只会造成痛苦。
我实际上将公共数据拆分为自己的数据库。因此，应用程序＃1使用db＃1，应用程序＃2使用db＃2，并且公共数据位于db＃3中，并且可由两个应用程序访问。稍微有点儿，我猜我最终会得到3个dbs，3个schema_migrations，我可以盲目地将我的迁移留在引擎中，并按照pivotal labs将它们包含在两个应用程序中 - 我的计划是做this之类的事情来完成所有这些工作，并设置通用模型来连接到他们自己的数据库，而不是应用程序数据库
坚持使用1个数据库和多个模式，并以某种方式设置任务仅运行引擎迁移，使用仅锁定到自己的模式的帐户 - 这样就可以创建自己的schema_migrations。
< / LI>我有点觉得瘫痪，因为我不确定什么是最不好的选择。 3或4感觉“最好”，但不是很好。
答案 0 :(得分：1)
我认为3是最好的选择。但是，我通过api公开了常见的db＃3数据。也就是说，有一个用于管理共享数据的应用程序（HTML管理界面和其他应用程序连接的json提要）。
保持共享数据应用程序非常简单。只是对数据的CRUD操作。因此，其他两个应用程序将从共享数据应用程序中获取数据，进行操作以匹配本地要求，然后显示它;或允许输入 - 操作输入以匹配共享结构，然后通过共享数据应用程序的API更新/创建操作保持。
答案 1 :(得分：0)
作为对此的更新，由于两个应用程序的紧密耦合以及昨天出现的其他需求，我最终将迁移从两者中移除并使用active_record_migrations来管理和编排两个应用程序的迁移。
实际上，我可以通过使用虚拟或主应用程序来完成同样的操作，但这感觉有点干净。
然而，这是以能够在迁移中有效使用模型为代价的。对于我的用例，这根本不重要。