我的任务是扩展现有的银行应用程序以支持多租户。该应用程序目前服务于约 100 家公司，拥有约 4000 名用户；并准备好迎接重大增长。
细节有点复杂，所以这里有一个简短的历史：
最初，这个门户是为一家抵押贷款公司创建的，该公司管理 3 种类型/角色的账户：
- 内部 - 可以管理所有用户、银行、经纪人和抵押文件的抵押公司员工
- 客户 - 可以只管理他们的用户和抵押文件的银行员工
- 经纪人 - 独立承包商只能访问他们的抵押文件
一帆风顺，然后是客户#2：为每个新的抵押贷款公司创建了一个单独的实例。采用该系统。单独的实例不可避免地演变成单独的版本。现在已经迁移到一个单一的、可配置的版本，但每个抵押公司仍然存在一个单独的实例。
第一个转折是越来越多的经纪人为不止一个抵押贷款公司工作，并被迫为花旗、GMAC、Chase 和 BoA 保持单独的登录。
第二个转折点是银行员工必须为每个抵押贷款公司的实例维护一个登录名。（因为单独的数据库）
第三个转折是，更多的银行想要像抵押贷款公司那样的实例，并要求与他们合作的所有抵押贷款公司都来找他们（部分由上面的转折#2驱动。）
实际上有银行在 1 个实例中将文件分配给抵押公司，然后抵押公司的员工正在登录银行实例并将数据双重输入到他们自己的实例中。都在同一个数据库服务器上！
因此，我们希望/需要将这个 N 平方膨胀整合到 1 个多租户数据库中，并为我们的客户消除重复帐户和重复数据输入。有时我们的客户是银行，有时是抵押贷款公司。它就像银行和抵押贷款公司的社交网络。
问题： 1. 这是一个非常标准的 MT 实现吗？2. MT 解决方案中是否存在共享对象？（即系统中只有一个 GMAC） 3. 有没有我们可以用作参考的网站？4. 是否对银行、经纪人和抵押贷款公司彼此隐藏的建议，除非他们在 MT 之前有关系？一种选择是将其打开：一个目录，他们都可以在其中与新的银行、经纪人和抵押贷款公司联网 - 或者 - 关闭它，隐藏所有实体，并要求每个实体提供另一个实体的 GUID 以发现和链接到他们。
我对 MT 测试版的基本架构想法：
1. 包含每个实例的每个不同用户帐户的用户表 2. 每个实例的每个抵押公司和银行的组织表 3. UserOrgLink 表将用户链接到具有角色的组织 4. RoleType 表 5 . 大多数表中的 OrgID 列
我欢迎并重视所有的意见、想法和批评。