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