Это конкретный ответ, но только некоторые некоторые аспекты, которые вы можете учитывать при разработке этого.
Что касается общей информации, я думаю, что наиболее важной частью здесь является определение отношений между клиентами и ролями.и права каждого клиента в отношении других клиентов.Лучше всего начать с определения того, что именно можно сделать.
Пример:
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, эти отношения могут быть загружены в сеанс, когда клиент входит в систему вместе с соответствующими идентификаторами арендаторов.
(Исходя из предоставленной информации, я склоняюсь к тому, что это может касаться приложения, а не клиента. Чтобы проиллюстрировать это, замените значения 'cust' в приведенных выше таблицах на App.)
Создайте отдельные сайты для каждого приложения, так как я предполагаю, что каждое приложение имеет уникальную цель, хотя и имеет общие функции.
Возможно, необходима другая база данных конфигурации, если есть другие перекрестные данныеотношения.БД будет хранить всю информацию об арендаторе (включая связи с другими приложениями) для каждого приложения.Причина этого предположения заключается в том, что, как я вижу, у вас есть три отдельных мультитенантных приложения, независимых друг от друга с использованием подхода с общей базой данных, но каждое приложение должно взаимодействовать с другим приложением на некотором уровне.
С точки зренияклиентам в БД, я бы тогда предложил, чтобы таблица «Клиенты» была ограничена БД Config.После этого вы можете создать базу данных контента на основе требований каждого приложения.