我目前正在设计一个网络应用程序，在那里我将有客户注册为公司.每家公司都将拥有自己的一组用户.当我设计这个的时候，我想知道哪种方法最有效.我看到像Fogbugz或Basecamp这样的网站使用子域.在有子域的情况下，您是否每个子域都有一个数据库实例？我想知道是否建议每个公司都有一个数据库实例，或者我是否应该有某种公司表，并从一个数据库管理公司和用户数据/凭据.
哪种方法是最好的？有没有关于这个主题的文献(例如，任何网络或书籍)？
提前谢谢！
我目前正在设计一个网络应用程序，在那里我将有客户注册为公司.每家公司都将拥有自己的一组用户.当我设计这个的时候，我想知道哪种方法最有效.我看到像Fogbugz或Basecamp这样的网站使用子域.在有子域的情况下，您是否每个子域都有一个数据库实例？我想知道是否建议每个公司都有一个数据库实例，或者我是否应该有某种公司表，并从一个数据库管理公司和用户数据/凭据.
哪种方法是最好的？有没有关于这个主题的文献(例如，任何网络或书籍)？
提前谢谢！
您必须权衡您的 Select ，因为其中一些将是见仁见智的问题，对于您的实现可能是不可行的.
也就是说，由于这些原因，我会考虑单数据库方法:
Maintenance:当按已注册的"客户端"运行数据库时，您将很容易遇到这样一种情况，即您对应用程序模式所做的任何更改或升级都必须应用于每个数据库实例.这很快就会变得荒谬可笑.
Convenience:您可能需要分析和使用统计数据，或者以某种方式管理所有这些数据库.要try 为所有数据库聚合相同的查询，查询单个数据库相对来说比较简单.这是不会扩大规模的.
Scalability*:如2中所述，您将需要一种特殊类型的聚合来查询有关您的客户端和整个应用程序的信息.你的应用程序越大，你的查询就越复杂.另一个问题是，如果一个客户端比另一个客户端使用这个应用程序的次数多得多，你会被鼓励优化什么？您的应用程序、较大客户端的数据库还是较小客户端的数据库？不要忘记您所做的任何更改，必须将其复制到所有数据库.
Backups:您只需创建一个转储并将其存放在某个地方，即可轻松备份一个数据库.获得Backups0个客户端，现在您必须运行Backups0个数据库转储，并对它们进行足够好的命名，以便在一个数据库损坏时能够识别它们.你怎么知道会不会发生这种情况呢？数据库错误将定位到特定的数据库错误，而不是整个应用程序.
UI:用户注册或被邀请使用你的应用程序，并且属于某个特定的客户端.您要将该用户帐户保存到客户端的数据库中吗？如果是这样的话，请参阅可伸缩性，了解当用户想要更改密码或发送邮箱时处理该数据的问题.那么，你是否告诉用户让你知道他们在哪个数据库中，这样你就可以找到他们？
Simplification:您的每个客户端都有一个数据库，并且只想使用单个数据库.如何在不造成重大 destruct 的情况下将它们合并在一起？如果您使用自动递增的ID，将会有主键冲突；如果您决定只重新生成键，则书签URL将中断；表中的外键将不再指向正确的记录.您的数据完整性将会付诸东流.
您提到了通过自定义子域名提供产品的"白标"服务.我不知道这些是如何工作的，但子域只是他们的DNS区域文件中的一个基本CNAME或A记录.添加这些内容的过程可以自动进行，应用程序的设计和一些服务器配置可以将这些子域链接到正确的帐户和数据.它们只是URL，所以可能在后台，应用程序没有区分:
http://client.example.com
http://example.com/client
不过，总的来说，你可能会认为所有这些问题都是你可以而且更愿意解决的.然而，要注意的是，这样做可能会让你自食其果，你可以从精心设计的单一数据库模式和精心抽象的前端中获得更多.
*@xQbert提到了多数据库可伸缩性的真正好处.我修改了这个答案，以澄清我更关心其他方面.