这是一个具体的答案,但只是您在设计时可能会考虑的一些方面。
关于共享信息,我认为这里最重要的部分是定义客户之间的关系以及每个客户相对于其他客户拥有的角色和权利。最好的方法是首先确定可以做什么。
例子:
Read Only|cust1|cust2|cust3
---------+-----+-----+-----
customer1| 1 | 1 | 0
customer2| 0 | 1 | 0
customer3| 1 | 0 | 1
Write |cust1|cust2|cust3
---------+-----+-----+-----
customer1| 1 | 1 | 0
customer2| 0 | 1 | 0
customer3| 0 | 0 | 1
所以在上面,customer1 可以读取和写入(更新)customer2 的数据。
话虽如此,主要问题是对这些关系进行建模,即共享信息。使用@TFD 的建议,这些关系可以在客户登录时与相关租户 ID 一起加载到会话中。
(根据提供的信息,我的另一个倾向是,这可能是每个应用程序的问题,而不是客户唯一的问题。为了说明这一点,请将上表中的 'cust' 值替换为App
。)
为每个应用程序创建单独的站点,因为我假设每个应用程序都有一个独特的目的,尽管有共享的功能。
如果存在其他交叉数据关系,可能需要不同的 Config DB。数据库将存储每个应用程序的所有租户信息(包括与其他应用程序的关系)。这个建议的原因是,据我所见,您有三个独立的多租户应用程序,它们使用共享数据库方法相互独立 - 但每个应用程序都需要在某种程度上与另一个应用程序进行交互。
就数据库中的客户而言,我建议将“客户”表限制在配置数据库中。然后,您可以拥有基于每个应用程序要求的内容数据库。