database-design - 大型 Web 应用程序的数据库架构

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

7年前关闭。




Improve this question




许多 SaaS Web 应用程序服务都有基于公司的概念。因此，每个使用该服务的公司都有自己的一组用户、文件和其他数据。 Web 应用程序通常如何在 DB 端处理这个问题？他们是否为每家公司创建了一个新数据库(包含与该公司相关的数据表)？或者他们是否有某种 company_id 关系来从单个数据库中选择相关数据？

Answer 1

几个月前，我们在一个经常被组织使用的产品中遇到了这个问题，而这些组织又为多个客户提供服务。他们来找我们要求我们修改我们的 SaaS 系统，以便他们可以为他们的每个客户创建完整的、独立的网站(我们构建了一个在线的、特定于域的网站构建工具)。

一个简短的总结:将每个人放在一个数据库中似乎很明显，但是，随着您深入探究，您会发现它并不总是一成不变。在继续进行时，您需要牢记一些挑战。几点:

首先，仅将“Company_id”添加到几个表中是不够的。事实上，尽管 Sai 评论说为每个公司拥有一个数据库/应用程序是荒谬的，但由于为多个离散客户托管 SaaS 系统的潜在复杂性，这绝对是有意义的。如果您只是为几家不同的公司提供服务(例如为他们开具发票)，那么 Sai 的评论是正确的。但是，如果您向多个组织提供软件应用程序，则复杂性要高得多，而且离散数据库很可能是有序的。

其次，为多客户端数据库中更加复杂的用户查询和报告工作做好准备。例如，在构建我们的用户查询功能时，我们必须绝对确定组织之间不会有“渗漏”，因为涉及到受 HIPAA 保护的数据。这意味着查询和报告功能需要的工程水平远远超过以前的水平。在我们的例子中，我们的查询功能非常灵活，基本上允许用户动态构建查询(显然受到一些非常严格的约束 - 我们不接受 SQL!)。因此，我们必须确保每个查询都自动修改为使用“Company_ID”约束，无论数据的来源或提交查询的员工的权限如何。皱纹？我们的“ super 用户”分析帐户必须能够在没有这种限制的情况下运行查询……

第三，您可能还没有预料到需要分离多少东西。例如，我在站点中构建了一个非常复杂的“设置”对象，该对象在启动时从数据库中提取设置并在“应用程序”对象(这是一个 .NET 应用程序)中维护它们。这一切都需要 float 来处理多个组织。

再举一个例子，过去对我们来说是唯一的字段(例如登录)现在必须作为 Company_ID、LoginID 键的一部分来完成。如果您从头开始构建，这不是一个大主意，但我们正在改造它。

无论如何，当我进行构建时，我惊讶地发现要做到这一点需要做多少工作。

第四，我总是使用“元编程”方法来构建软件。也就是说，我很少构建单一用途的页面，而是经常构建高度可定制的框架，以便于最终用户定制和内部代码重用。虽然我预计这将有助于过渡到多组织数据库，但通常没有!由于此类编码一开始通常相当复杂，因此 float 组织通常比我只有一个普通网页更困难。

最后，如果没有迫切需要共享数据(例如整体使用模式的分析)，那么您可能希望坚持使用离散数据库只是为了促进扩展。当您添加新的多组织数据库(第二个独立系统)时，我们的扩展通常涉及突然经历增长激增的现有客户。将它们从现有数据库中剥离并放到新服务器上比仅仅移动到具有现有数据库的新服务器要困难一些。

考虑到所有这些警告，您可能认为我不建议您构建一个能够在单个数据库上处理多个组织的系统。然而，情况并非如此:采用多组织方法确实取得了一些胜利!使用情况分析、跨组织报告、应用程序部署等都得到了显着增强。我只是想为您提供我们经验的好处，希望它能帮助您预测您可能会遇到的一些困难。