我目前正在设计一个网络应用程序，我将让客户注册为公司。每家公司都有自己的一组用户。在我设计这个时，我想知道哪种方法最有效。我看到像fogbugz或basecamp这样使用子域的网站。在子域的情况下，每个子域都有一个数据库实例吗？我想知道是否建议每个公司有一个数据库实例，或者我是否应该有某种公司表，并从一个数据库管理公司和用户数据/凭证。
哪种方法最好？是否有关于这个主题的文献（即任何网络或书籍）？
提前感谢！
答案 0 :(得分：22)
你必须权衡你的选择，因为其中一些是意见问题，可能对你的实施不可行。
话虽这么说，我考虑采用单一数据库方法，原因如下：
维护：在按照已注册的“客户”运行数据库时，您将很容易达到对应用程序架构所做的任何更改或升级必须应用于每个单独的情况数据库实例。这将变得荒谬，快速。
便利性：您可能需要分析和使用统计信息，或管理所有这些数据库的某种方式。查询单个数据库对于尝试为所有数据库聚合相同查询而言相对微不足道。这不会扩展。
可扩展性 *：如2中所述，您需要一种特殊的聚合方式来查询有关您的客户以及整个应用的信息。您的应用越大，查询就越复杂。另一个问题是，如果一个客户使用的应用程序比另一个客户端多得多，您会被鼓励优化什么？您的应用程序，更大的客户端数据库，还是较小的客户端？不要忘记你做的任何改变都必须复制到所有数据库。
备份：只需创建转储并将其存放在某处，即可轻松备份一个数据库。获得一千个客户端，现在您必须运行1000个数据库转储，并将它们命名为足以在一个数据库损坏时能够识别它们。你怎么会知道这是否发生？数据库错误将本地化为特定错误，而不是整个应用程序。
用户界面：用户注册或被邀请使用您的应用，属于一个特定的客户端。您要将该用户帐户保存到客户端的数据库吗？如果是这样，请参阅当用户想要更改其密码时使用该数据的问题的可扩展性，或者您希望通过电子邮件发送它们。那么，您是否告诉用户让您知道他们所在的数据库，以便您找到它们？
简化：每个客户端都有一个数据库，并且只想使用一个数据库。如何在不显着破坏的情况下将它们合并在一起？如果您使用自动递增ID，则会出现主键冲突;如果您决定重新生成密钥，则书签URL将会中断;跨表的外键将不再指向正确的记录。您的数据完整性将会下降。
您提及通过自定义子域提供其产品的“白标”服务。我不知道这些是如何工作的，但是子域只是DNS区域文件中的基本CNAME或A记录。添加这些内容的过程可以自动完成，应用程序的设计和一些服务器配置可以处理将这些子域链接到正确的帐户和数据。它们只是URL，因此可能在后端，应用程序不区分：
http://client.example.com
http://example.com/client
总的来说，您可能会认为所有这些问题都是您可以并且希望处理的问题。但要注意的是，这样做可能会让你自己陷入困境，而且你可以通过精心设计的单一数据库架构和精心设计的前端来获得更多。
* @ xQbert提到了多个数据库的可伸缩性的真正好处。我修改了这个答案，以澄清我更关注其他方面。