2 rails 应用程序 - 使用通用引擎共享数据答案

【问题标题】：2 rails apps - shared data using common engine2 rails 应用程序 - 使用通用引擎共享数据
【发布时间】：2015-11-04 12:57:32
【问题描述】：

我从一个 Rails 应用程序开始。非常简单，主要是只读的，用于业务线应用程序的前端（使用视图支持来检索数据） - 使用一些标准表来扩充视图。

我现在需要在一个新应用程序中使用相同的数据集（这两个应用程序虽然共享相同的数据，但工作方式不同，因此尝试将它们合并到同一个应用程序中并非易事）。

我认为将可以重用的模型拆分到自己的引擎中并让 2 个应用程序共享数据库是最简单的方法。

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

在此基础上，我想如果我给每个应用程序一个表前缀，或者使用不同的模式来命名它们 - 这样每个应用程序都有自己不同的表来存储它们不共享的东西，但我可以轻松地重用现有视图无需复制它们。

这两个选项似乎都很好用，除了我忘记了公共视图和数据的迁移。

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

由于这 2 个应用程序无论如何都是紧密耦合的，所以我的通用数据引擎中根本没有迁移 - 对视图/表的任何更改都将由“第一个”应用程序处理。这似乎有点讨厌，因为模型现在包含在一个单独的引擎中。我不喜欢在引擎中进行迁移然后将它们复制到其中一个的想法，因为这基本上是一回事。
我使用pivotal labs 建议，但添加一些代码来检测它是否在“第一个”应用程序中，并且仅适用于该应用程序。如果我不这样做，我最终会得到包括引擎迁移在内的两个应用程序，这会导致两个应用程序都尝试运行相同的迁移，并且只会造成痛苦。
我实际上将公共数据拆分到它自己的数据库中。所以应用程序#1 使用数据库#1，应用程序#2 使用数据库#2，公共数据存放在数据库#3 中，两个应用程序都可以访问。稍微花点时间，我猜我最终可以得到 3 个 dbs，3 个 schema_migrations，我可以盲目地将我的迁移留在引擎中，并按照pivotal labs 将它们包含在两个应用程序中 - 我的计划是像this 这样的东西来完成所有这些工作，并设置通用模型来连接到他们自己的数据库，而不是应用程序数据库
坚持使用 1 db 和多个架构，并以某种方式设置一个任务以仅运行引擎迁移，使用仅锁定到其自己的架构的帐户 - 这样它就创建了自己的 schema_migrations。

我有点不知所措，因为我不确定什么是最不糟糕的选择。 3 或 4 感觉“最好”，但不是很好。

【问题讨论】：

【解决方案1】：

我认为 3 是最好的选择。但是，我会通过 api 公开常见的 db #3 数据。也就是说，拥有一个用于管理共享数据的应用程序（HTML 管理界面，以及供其他应用程序连接的 json 提要）。

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

【讨论】：

尽管我希望在公共数据前面有一个 API，但这两个应用程序将以我不知道的方式对数据进行分组和执行不同的操作' d 提供 2 个 2 个应用程序，而不只是为它们都提供 API 方法——这会很快变大。要么，要么我必须为大量对象提供 JSON 提要，然后在客户端应用程序中进行处理。这似乎非常浪费。如果我可以直接访问数据库，这似乎更容易。我只是在努力避免这种情况吗？您是否仍然认为在他们之间有一个 API？
这取决于查询的变化程度。如果是运行相同的复杂查询而仅更改几个变量（例如周期的开始和结束）的情况，则可以通过 JSON api 轻松公开。如果查询变化很大，那么您可能必须直接访问数据库。在 rails 应用程序中定义第二个连接是相当简单的。我认为主要标准不是查询的复杂性，而是需要修改多少。更改越多，访问数据库连接就越容易。
感谢您的想法雷吉。非常感谢

【解决方案2】：

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

实际上我可以通过一个虚拟或主应用程序来做同样的事情，但是这感觉有点干净。

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

【讨论】：