简短摘要：将每个人放在一个数据库上似乎显而易见,但是,当你深入探究时,你会发现它并不总是干脆.在您继续操作时,您需要记住一些挑战.几点：

首先,仅将“Company_id”添加到几个表中是不够的.实际上,尽管Sai的评论认为每个公司都有一个数据库/应用程序是荒谬的,但由于托管多个独立客户端的SaaS系统的潜在复杂性,绝对存在这种情况.如果您只是为几家不同的公司服务(例如为他们创建发票),那么Sai的评论是完全正确的.但是,如果要向多个组织提供软件应用程序,则复杂性要高得多,而且离散数据库可能很有序.

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

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

再举一个例子,以前对我们来说唯一的字段(例如登录)现在必须作为Company_ID,LoginID键的一部分完成.如果你是从头开始构建,这不是一个很大的想法,但我们正在进行改造,所以它是.

无论如何,当我继续构建时,我很惊讶地发现需要做多少工作才能做到这一点.

第四,我总是使用“元编程”方法构建软件.也就是说,我很少构建一个单一目的页面,而是经常构建一个高度可定制的框架,以便于最终用户定制和内部代码重用.虽然我预计这将有助于向多组织数据库的过渡,但它往往没有！因为这样的编码通常起初相当复杂,所以浮动组织通常比仅仅拥有一个香草网页更困难.

最后,如果不需要共享数据(例如分析整体使用模式),那么您可能希望坚持使用离散数据库来简化扩展.当您添加新的多组织数据库(第二个离散系统)时,我们的扩展通常涉及突然出现增长激增的现有客户.将它们从现有数据库剥离到新服务器上比仅使用现有数据库迁移到新服务器要困难一些.

考虑到所有这些警告,您可能会认为我建议您不要构建能够在单个数据库上处理多个组织的系统.但事实并非如此：采用多组织方式有一些真正的胜利！使用分析,跨组织报告,应用程序部署等都得到了显着增强.我只是想为您提供我们的经验,希望它能帮助您预测您可能遇到的一些困难.