我的任务是扩展现有的银行应用程序以支持多租户。该应用程序目前为约100家公司提供约4000名用户;并准备好实现重大增长。
细节有点复杂，所以这里的历史很短：
最初，这个门户网站是为一家抵押贷款公司创建的，该公司管理着3种类型/角色的帐户：
顺利航行，客户＃2： 为每个新的抵押贷款公司创建了一个单独的实例。采用该系统。不同的实例不可避免地变成了单独的版本;现在已经迁移到单个可配置版本，但每个抵押贷款公司仍然存在单独的实例。
第一个转折点是，越来越多的经纪人为多家抵押贷款公司工作，并被迫为Citi，GMAC，Chase＆amp; amp;例如BoA。
第二个转折点是银行员工必须为每个抵押贷款公司的实例保持登录。 （因为单独的DB）
第三个转折点是，越来越多的银行想要像抵押贷款公司那样的实例，并要求所有与他们合作的抵押贷款公司来到他们身边（部分由上面的扭曲＃2驱动。）
< / LI>实际上银行在一个实例中将文件分配给抵押贷款公司，然后抵押贷款公司的员工登录银行实例并将数据加倍输入他们自己的实例。全部在同一个数据库服务器上！
因此，我们希望/需要将此N平方膨胀整合到1个多租户数据库中，并为我们的客户消除重复帐户和重复数据输入。有时我们的客户是银行，有时候是抵押贷款公司。它就像一个银行社交网络。抵押贷款公司。
问题： 1.这是一个非常标准的MT实现吗？ 2.在MT解决方案中共享对象是否常见？ （即系统中只有一个GMAC） 3.有没有我们可以用作参考的网站？ 4.关于是否隐藏银行，经纪人和银行的建议除非他们在MT之前有过关系，否则他们会互相抵押？一种选择是让它开放：一个目录，他们可以与新银行，经纪人和抵押贷款公司 - 或 - 使其关闭，隐藏所有实体，并要求每个实体提供另一个实体的GUID以发现＆amp;链接到他们。
我对MT beta的基本架构想法：
1.用户表，包含每个实例的每个不同用户帐户
2.每个抵押贷款公司的组织表和从每个实例银行
3. UserOrgLink表将用户链接到具有角色的Orgs
4. RoleType表
5.大多数表格中的OrgID列
我欢迎并重视所有的意见和建议。的批评。
答案 0 :(得分：0)
无论您做什么，都不要将OrgID添加到大多数表中。你最好保持Orgs完全分离（这种方式，如果你需要将数据库移动到另一台服务器，或者合并，你不必提取或合并一个组织的数据）。使用包含用户映射的控制数据库＆lt; - ＆gt;抵押贷款/银行 - 他们通过控制数据库进行身份验证，然后他们选择他们想要合作的公司。控制数据库可以告诉应用程序在哪里可以找到该公司的数据库。