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