假设我们有这种情况：
- www.main.com - 管理员（foo，bar等）可以根据自己的电子商务存储产品的主界面
- www.foo.com - 销售来自＆＃34; foo＆＃34;存储
- www.bar.com - 从＆＃34; bar＆＃34;出售商品的样品商店存储
问题在于找到一种集中数据库结构和模型的方法。
我更喜欢将每个商店保留在独立的应用中（因此我排除了rails引擎）。
例如，如果用户在＆＃34; foo＆＃34; store，我需要与主db进行交互并更新它。
我该怎么做？
2 个答案:
答案 0 :(得分：2)
使用＆＃34;一个数据库，一个应用程序＆＃34; Rails可以更好地工作。模型。有很多方法可以跨应用程序（宝石，引擎，git子模块等）共享模型，但这些方法都不是很好。您最终会在开发，部署和测试过程中引入大量开销。你也会在代码之间邀请许多隐藏的依赖关系，因为Rails没有为你提供简单的方法来保持干净的抽象（例如，你为商店Foo编写了一个助手，然后你的同事在商店Bar中使用了那个助手，然后每当你改变Foo，Bar就会破坏。
我推荐使用集中式API方法：
- api.foobarmain.com - 一个应用程序/服务，为所有商店的所有功能提供RESTful API。
- 此应用程序包含所有数据库模型，并将它们作为API中的资源公开，供其他应用程序进行交互。
- 如果您需要，此应用可以为所有商店设置管理界面。或者，管理UI可以是API的另一个客户端。
- www.foo.com - 在api.foobarmail.com与API交互的完整堆栈应用
- 没有与API的共享数据库连接，您需要进行交互的所有内容都必须通过API公开。
- www.foo.com和www.bar.com之间不会有共享代码。代码重用仅通过使用相同的API应用程序/服务来实现。
- 从www.foo.com的角度来看，模型层（在MVC中）由API提供动力，而不是由数据库提供动力。
- 如果您只需要存储特定于www.foo.com的数据，您仍可以在www.foo.com上拥有自己的数据库。
- www.bar.com - 另一个与API交互的完整堆栈应用
- 等......
答案 1 :(得分：0)
如果您使用的是Postgresql，则另一种方法是使用多个架构。我有一个与我即将开始的新项目有类似的问题。
您可以使用gem 'apartment'来处理不同的架构。查询会有点复杂，但是使用不同的模式，您最终会得到一个数据库，您可以创建不同的命名空间来进行相应的响应。
您可以设置应用程序根据域或子域选择正确的架构。
以下是链接：https://github.com/influitive/apartment