基于SaaS模式下的数据库架构设计策略(再思考)

原以为基于SaaS架构的数据库数据隔离的设计，无外乎就是3种设计模式： （1）独立数据库 （2）Share数据库，独立Schema （3）Share数据库.Share Schema，每个表均加以个 tenentid(租户ID),这3种模式的优缺点大家都提了很多了，SaaS架构设计的前辈/我/阿里软件

原以为基于SaaS架构的数据库数据隔离的设计，无外乎就是3种设计模式：
（1）独立数据库
（2）Share数据库，独立Schema
（3）Share数据库.Share Schema，每个表均加以个 tenentid(租户ID),这3种模式的优缺点大家都提了很多了，SaaS架构设计的前辈/我/阿里软件最新出的那本书，也都是这么讲的，包括2年前微软推出的SaaS架构设计指南，也都是这么说的。最近一直在思索这个问题，难道真的就没别的出路了？

这3种模式中，第一种做SaaS架构的，相信都不会采纳了，但是第2种与第3种设计的架构之争，常常是谁也说服不了谁。这两种架构，各有优缺点，而且都还很鲜明。

第2种架构设计，Share数据库，独立Schema，比较适用于复杂MIS的应用，数据库关联比较多；而第3种架构设计，适合简单的网站应用，比如网上书店，Performance显然第3种架构比较好，但是数据隔离权限太复杂，对程序员要求比较高，第2种由于Performance问题比较大，对软件系统架构师要求很高。而且第2种，在对B2B网站和供应链/进销存系统整合的应用中，如果综合查询所有租户(供应商/客户)的统计数据，则几乎是不可能的，每个租户之间的数据很难综合共享，每个之间都是数据孤岛。

难道真的就没有更好的设计了吗？后来，在每天不断的苦苦求索当中，终于看到了一缕曙光，利用数据库的特性，也许可以把第2类和第3类设计的优点整合起来，就可以解决这个难题了，只是牺牲了跨数据库的优点，但是对应用程序架构的设计，改动是不大的，而且综合了设计2和设计3的优点，个人认为，这种牺牲，在具体应用中，还是值得的。