我正在设计一种服务于一些商业实体的服务。从逻辑上讲，它将分为两部分：
它是 play 2.x 框架，计划托管在 heroku 中。目前尚不清楚如何分解实例和数据库内容。
我应该为客户分解数据库：业务实体 - 一个数据库吗？或者我应该将所有数据存储在一个数据库中，但为拥有某行的业务实体的所有表添加 ID？这个决定可能会带来哪些问题（性能、管理、扩展）？
如果我将选择划分数据库，我该怎么做？为此，我需要为该实例所属的客户端启动带有数据库的应用程序实例。因此，我们有可能成为扩展障碍的非均匀实例。据我所知，heroku 不支持非统一（网络）实例。
请帮忙，我完全被困在这里。
预期堆栈：
所有这些（Scala 除外，可能是 Play 2.0）都是可以互换的。
这是一个非常经典的问题。您有许多客户，您想知道是否应该为每个客户创建单独的数据库 - 或者他们是否应该共享一个数据库。
我建议从一个共享数据库开始，然后使用它直到你扩展它。想想让每个客户端都有自己的数据库实例的一些缺点：
就像您提到的那样，模式管理可能很困难。您需要编写工具来维护所有服务器上的所有数据库。
如果您告诉客户您以这种方式构建系统，其中一些可能会促使您分叉数据库。换句话说，他们可能会争辩说：“我有自己的数据库！我想要一个只属于我自己的新表。”
跨服务器/数据库运行查询有点困难。如果您想计算所有客户拥有多少物品，您必须考虑一下。
但是，如果您想从基于客户端 ( http://en.wikipedia.org/wiki/Shard_(database_architecture) ) 的分片开始，您可以考虑：
如前所述，您需要一些工具/脚本来为客户端启动新的数据库实例。通常，这些工具需要用配置信息“播种”数据库——比如为地址填充状态表。
您将需要一个工具来监视/维护数据库。启动一个，停止另一个，查看一个是否有高 CPU 使用率等。
您需要某种系统来汇总所有客户端的统计信息。
您将需要一个工具来推出架构更改，并计划如何在他们的 Web 应用程序运行时优雅地升级数据库。
总的来说，我建议从小而简单的开始，只有在你到达那里时才开始担心规模。