我正在构建一个SAAS应用程序，我们正在讨论每个客户端与共享数据库之间的一个数据库。我已经阅读了很多内容，其中包括一些主题，但我仍然有很多疑问。
我们的平台应该由每个客户高度定制。 （他们应该能够拥有自定义表并向现有表添加自定义字段）。 在这种情况下，多数据库方法看起来很棒。
问题是。我的“用户”表应该在主数据库中还是在每个客户端数据库中？ 用户可能拥有一个或多个组织，因此它将存在于多个数据库中。 那么，像国家/地区表这样的通用表呢？
进入master数据库是有意义的。但是我有许多带有created_by字段的表，它们具有用户的外键。还有客户端的一些权限相关表。
如果多个数据库，我会失去外键的强大功能，这意味着对数据库的查询更多。我知道我可以在数据库之间使用交叉连接，如果它们在同一台服务器中，那么我就会失去可扩展性。 （我将来可能需要有多个数据库服务器）。 我已经考虑了联邦表。不确定性能。我使用的技术是php和symfony 2框架以及数据库的mysql。
另外，我担心维护这样的系统。我们可以创建一些脚本来自动化所有数据库中的模式更改，但是如果我们有10k客户端意味着10k数据库。
您对此有何看法？ 我的应用程序的主要特点应该是灵活性，所以如果客户需要比基本平台没有的更具体的东西，应该可以为他做。
答案 0 :(得分：19)
这里有一些经典问题。你去过http://highscalability.com/吗？那里有一些好的案例研究。
根据个人经验，如果您尝试在一台服务器上共享客户端，您会发现一个非常成功/活跃的用户将占用该计算机的所有资源。我们在SAAS中有一个客户端破坏了共享服务器，我们不得不将他移到其他地方。
我会将全局枚举转换为服务。您可以为国家/地区列表，状态列表等创建一个中央数据库，并将其置于Web服务层之后。此外，在该数据库中，您可以拥有用户管理/管理哪些服务器属于哪个用户等。您可以创建一个管理门户，读取/写入此数据库以管理您的用户群。
如果我再次做SAAS，我会从小开始，等待疼痛发作。你真正想要的是在它们发生时解决扩展问题的好工具。让一些脚本准备好跨服务器进行滚动模式更改（一旦有多个服务器，就无法避免这种情况）。在修改模式时使用脚本来删除计算机。有脚本将用户从共享服务器迁移到专用服务器。
考虑从中央数据库设置复制。这将抽取每个用户分区/数据库所需的全局信息，而无需编写大量代码。
但是我见过的最重要的建议 - 并且经验丰富 - 不要太努力建立下一个规模的Facebook。在开始担心主要的可扩展性问题之前，先简单地看看实际发生了什么。您可能会感到惊讶，因为用户群的扩展可以很好地扩展，哪些不可扩展。