问题标签 [multi-tenant]

在为多个客户端设计的以数据库为中心的应用程序中，我一直认为为所有客户端使用单个数据库“更好” - 将记录与适当的索引和键相关联。在收听 Stack Overflow 播客时，我听到 Joel 提到 FogBugz 每个客户端使用一个数据库（因此，如果有 1000 个客户端，则将有 1000 个数据库）。使用这种架构有什么好处？

我知道对于某些项目，客户需要直接访问他们的所有数据——在这样的应用程序中，很明显每个客户都需要自己的数据库。但是，对于客户端不需要直接访问数据库的项目，每个客户端使用一个数据库有什么好处吗？似乎就灵活性而言，使用具有单个表副本的单个数据库要简单得多。添加新功能更容易，创建报告更容易，并且更易于管理。

在我听到 Joel（一位经验丰富的开发人员）提到他的软件使用不同的方法之前，我对“所有客户的一个数据库”方法非常有信心——我对他的决定有点困惑......

我听说有人提到数据库会因大量记录而变慢，但任何具有某些优点的关系数据库都不会出现这个问题——尤其是在使用适当的索引和键的情况下。

非常感谢任何输入！

我正在开发一个网站，将管理多个实体的数据。实体之间不共享数据，但它们可能属于同一客户。客户可能希望从单个“仪表板”管理他们的所有实体。那么我应该为所有事情都建立一个数据库，还是将数据分开到单独的数据库中？有最佳实践吗？有什么积极/消极的：

• 整个网站的数据库（实体有一个“customerID”，数据有“entityID”）
• 每个客户的数据库（数据有“entityID”）
• 每个实体的数据库（数据库与客户的关系在数据库之外）

多个数据库似乎会有更好的性能（更少的行和连接），但最终可能成为维护的噩梦。

我见过以许多不同方式托管的 SaaS 应用程序。跨多个数据库拆分功能和模块是个好主意吗？例如，将 User 表放在一个 DB 上，将功能/应用特定表放在另一个 DB 上，或者将其他常用共享表放在另一个 DB 上？

我们正在用 ASP.NET 构建一个多租户网站，我们必须让每个客户配置自己的安全模型。他们必须能够定义自己的角色，并将用户置于这些角色中。做这个的最好方式是什么？

有很多简单的 page_load 事件示例，其代码如下：

但这会对代码中的组和权限进行硬编码。如何使其用户可配置？

在StackOverflow 播客中没有。在19 日，Joe 描述了 Fogcreek 的决定，即每个客户端都拥有一个数据库，而不是所有客户端都拥有一个数据库。这让我想到了以下几点。

1. 假设我有1000 个用户。
2. 每个用户有100 个客户。
3. 每个客户有1000 种产品。

所以这意味着我将有1000 x 100 x 1000 = 100,000,000 个产品与用户相关联。现在，如果我对一个用户及其所有客户的产品进行连接表查询，那么如果我为此目的只使用一个数据库，那么合理的查询时间应该是多少？

更新

也许我的问题不够清楚。假设我需要对上面描述的数据集进行各种时髦的查询（最小、最大、组等），是否会很慢（或没有）到拥有多个数据库策略更有意义的地步，例如. 1 DB/客户端、数据库分片等

我正在开发一个旨在简化公司工作流程和项目管理的 PHP 应用程序，比如说Basecamp和GoPlan。

我不确定数据库方面的最佳方法是什么。我应该使用单个数据库并向每个表添加特定于客户端的列，还是应该为每个新客户端创建一个数据库？一个重要的因素是自动化：我希望创建一个新客户变得非常简单（也许可以为自己注册）。

我可以考虑使用一个数据库的可能缺点：

• 缺乏可扩展性
• 安全问题（尽管一开始就不应该存在错误）

您对此有何看法？您对上述公司最有可能选择哪种解决方案有任何想法吗？

我正在将我们的应用程序从“一组代码和一个数据库”更改为“一组代码到多个数据库（每个客户一个数据库）”。

原始代码是 VS2005 ASP.NET(VB) 和大量 XSD 在单独的 DLL 中。web.config 的 ConnectionString 将在运行时覆盖存储在 DLL 中的连接字符串。

现在我需要在每次声明数据适配器/数据集/表时更改 ConnectionString，因为调用可能会与上次调用不同的数据库。

有人对此有任何提示吗？

请记住，每个 webapp 都有自己独立的数据库（但所有数据库都在同一个数据库服务器中）。

场景是我有一个多租户 saas 应用程序 - 我为每个客户部署相同的应用程序。每个客户都在一个名为 的数据库上工作db_cid，其中cid是客户 ID，即唯一的客户标识符。

使用休眠模式。

在多租户架构 Web 应用程序中验证 URL 的最佳方法是什么，以确保来自一个组织的用户不会通过更改查询字符串参数来访问另一个组织的数据。我不想对每个页面加载进行验证。该应用程序是在 ASP.net 3.5 上构建的。

我正在设计一个必须支持“子站点”的 ASP.NET 应用程序。

这个想法是让超级管理员管理所有用户、全局应用程序设置和子站点。每个子站点都有一些自己的设置（例如本地管理员、徽标和欢迎消息），每个子站点都有自己的注册用户列表。

这与使用 Joomla、SharePoint 或 DotNetNuke 等 CMS 获得的结果非常相似。事实上，我很想使用这样的平台，但其他项目要求阻止我这样做。

在这一点上，我的问题非常笼统：

1. 使用ASP.NET 2.0 Membership，我将如何指定超级管理员并根据用户注册的 SubSite 对用户进行分类？
2. 我将如何实现子站点（应该使用什么模式等）？我对解释其他人如何做到这一点的文章特别感兴趣。我想学习其他人已经获得的最佳实践，而无需花费数天时间深入研究像 DotNetNuke 这样的大型开源项目的源代码。

我在 ASP.NET MVC 1.0 中实现了这一点，所以类似的例子会很有帮助。