2015-11-04 66 views
1

我已经开始使用单个Rails应用程序。非常简单,基本上只读,用于一系列业务应用程序的前端(使用视图支持检索数据) - 使用一些标准表来扩充视图。2 rails应用程序 - 使用通用引擎共享数据

我现在需要在一个新的应用程序中使用相同的一组数据(这两个应用程序共享相同的数据,工作方式不同,尝试将它们合并到同一应用程序中并不重要)。

我觉得把我可以重复使用的模型分割成他们自己的引擎并让这两个应用程序共享数据库是最容易的。

添加一个API并让这两个应用程序查询是一个选项,但实际上我不确定我能否提供一个API来正确满足这两个应用程序,因为它们以不同方式使用数据。

在这个基础上,我想到了如果我给每个应用程序一个表前缀,或者使用不同的架构来命名空间 - 这样每个应用程序都拥有它们不共享的不同表格,但我可以轻松地重用现有视图而不必复制它们。

这两个选项似乎都很好,除了我忘记了常见视图和数据的迁移之外。

所以,我能想到的唯一的事情是:

  1. 由于2个应用程序有点紧反正耦合的,我有我的公用数据引擎不迁移在所有 - 任何修改的意见/表将由“第一”申请处理。这似乎有点令人讨厌,因为模型现在被包含在一个单独的引擎中。 我不喜欢在引擎中进行迁移然后将它们复制到一个或另一个中的想法,因为这基本上是相同的。

  2. 我使用pivotal labs的建议,但添加一些代码来检测它是否在“第一”的应用程序,并只适用于该。如果我没有这样做,我最终会遇到包括引擎迁移在内的两个应用程序,这会导致这两个应用程序尝试运行相同的迁移,并导致除了痛苦之外的任何事情。

  3. 我实际上将普通数据分解到它自己的数据库中。因此,应用程序#1使用db#1,应用程序#2使用db#2,公用数据存放在db#3中,并且可由两个应用程序访问。随着有点虚弱,我猜测我最终可能会有3个数据块,3个schema_migrations,而且我可以盲目地将我的迁移留在引擎中,并按照pivotal labs将它们包含在两个应用程序中 - 我的计划是做类似this使所有这些工作,并有共同模型设置连接到他们自己的数据库,而不是应用程序DB

  4. 坚持1分贝和多个模式,并以某种方式设置任务来运行引擎迁移只,只使用一个锁定到它自己的模式的帐户 - 这样它会创建它自己的schema_migrations。

我有点瘫痪,因为我不知道什么是最不低劣的选择。 3或4感觉“最好”,但不是很好。

回答

1

我觉得3是最好的选择。不过,我会通过api公开数据库#3的数据。也就是说,有一个用于管理共享数据的应用程序(HTML管理界面和用于其他应用程序连接的json提要)。

保持共享数据应用程序非常简单。只需对数据执行CRUD操作。因此,其他两个应用程序将从共享数据应用程序中获取数据,进行操作以符合本地要求,然后显示它;或允许输入 - 操纵输入以匹配共享结构,然后通过共享数据应用程序的API更新/创建操作持久化。

+0

尽管我希望在公共数据前面有一个API,但是这两个应用程序将对这些数据进行分组和执行不同的操作,但我不知道该如何提供2个2而不是只为他们提供API方法 - 这将会非常快速。无论是那个还是我都必须为大量对象提供JSON订阅源,然后在客户端应用程序中执行处理......这看起来非常浪费。如果我可以直接访问数据库,似乎更容易。我只是想尽量避免这种情况?您的意见是否仍然想要在他们之间建立一个API? –

+0

这取决于查询改变了多少。如果只是一些变量运行相同的复杂查询(例如开始和结束时间段),可以通过JSON API轻松公开。如果查询变化很大,则可能需要直接访问数据库。在rails应用程序中定义第二个连接非常简单。我认为主要标准不是查询的复杂性,而是需要修改多少。更多的变化,更容易去数据库连接。 – ReggieB

+0

感谢您的想法Reggie。非常感谢<3 –

0

作为对此的更新,由于2个应用程序的紧密结合以及昨天出现的其他需求,我最终将迁移从两者中移出,并使用active_record_migrations来管理和编排两者的迁移应用。

有效地,我可以通过虚拟或主应用程序来完成相同的操作,但这种感觉会更清晰。

但是,这是以能够在迁移中有效使用模型为代价的。对于我的用例来说,这根本不重要。