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