Многопользовательская база данных с некоторыми общими данными

Question

У меня есть полная многопользовательская база данных с TenantID на всех арендованных базах данных. Все это работает хорошо, за исключением того, что теперь у нас есть требование разрешить арендованным базам данных "связываться" с общими данными. Так, например, пользователи могут создавать свои собственные «банковские» записи и связывать с ними учетные записи, но они также могут связывать счета с «глобальными» банковскими записями, которые являются общими для всех арендаторов.

Мне нужно элегантное решение, которое сохраняет ссылочную целостность

Пути, которые я придумала до сих пор:

1. Копировать : все общие данные копируются каждому арендатору, возможно, с флагом «Система». Изменения в общих данных влекут за собой огромные обновления для всех арендаторов. Возможно, самое простое решение, но мне не нравится дублирование данных
2. Специальный идентификатор : все ссылки на общие данные используют специальные идентификаторы (например, отрицательные идентификаторы). Это указывает на то, что TenantID не должен использоваться в отношении. Вы не можете использовать FK для принудительного применения этого и, конечно, не можете повторно использовать ID в арендаторах, если у вас есть ЛЮБОЙ FK. Только триггеры могут быть использованы для целостности.
3. Отдельные идентификаторы : все таблицы, которые могут ссылаться на общие данные, имеют ДВА ФК; один использует TenantID и ссылки на локальные данные, другой не использует TenantID и ссылки на общие данные. Ограничение указывает, что один или другой должен использоваться, а не оба. Это, пожалуй, самый "чистый" подход, но он кажется ... уродливым, но, возможно, не таким уродливым, как другие.

Итак, мой вопрос состоит из двух частей:

• Есть ли варианты, которые я не рассматривал?
• Кто-нибудь имел опыт работы с этими опциями и имеет отзывы о преимуществах / недостатках?

Answer 1

Коллега дал мне понимание, которое работало хорошо. Вместо того, чтобы думать о доступе арендатора как член, думайте об этом как доступ группы. Арендатор может принадлежать к нескольким группам, включая собственную указанную группу. Данные тогда принадлежат группе, возможно, определенной группе Арендатора, или, возможно, более общей.

Таким образом, «Мой Банк» будет принадлежать к группе Арендатора, «Местный Банк» будет принадлежать к региональной группе, к которой имеет доступ арендатор, а «Глобальный Банк» будет принадлежать к группе «Все».

Это сохраняет целостность, FK, а также добавляет возможность иметь иерархию арендаторов, не то, что мне вообще нужно в моем сценарии, но хорошая небольшая возможность.

Answer 2

На Citus мы создаем мультитенантную базу данных, используя PostgreSQL. Для общей информации мы храним ее в так называемых «справочных» таблицах , которые действительно копируются во все узлы. Тем не менее, мы сохраняем это синхронно и согласованно, используя 2PC, а также можем создавать отношения FK между справочными и нереферентными данными. Вы можете найти более подробную информацию здесь .