Base de données multi-locataires avec certaines données partagées

Question

J'ai une base de données multi-locataires complète avec TenantID sur toutes les bases de données hébergées. Tout ceci fonctionne bien, sauf que nous devons maintenant permettre aux bases de données hébergées de «lier» les données partagées. Ainsi, par exemple, les utilisateurs peuvent créer leurs propres enregistrements «Banque» et leur associer des comptes, mais ils peuvent également lier des comptes à des enregistrements bancaires «globaux» partagés entre tous les locataires.

je besoin d'une solution élégante qui maintient l'intégrité référentielle

Les façons dont je suis venu avec jusqu'à présent:

1. Copie: toutes les données partagées sont copiées à chaque locataire, peut-être avec un " Système ". Les modifications apportées aux données partagées impliquent d'importantes mises à jour pour tous les locataires. probablement la solution la plus simple, mais je n'aime pas la duplication des données
2. ID de spécial: tous les liens vers des données partagées utilisent spécial ID (par exemple les numéros d'identification négatifs). Ceux-ci indiquent que le TenantID ne doit pas être utilisé dans la relation. Vous ne pouvez pas utiliser un FK pour l'appliquer correctement, et vous ne pouvez certainement pas réutiliser les ID dans les locataires si vous avez un FK. Seuls les déclencheurs peuvent être utilisés pour l'intégrité.
3. ID séparés: toutes les tables pouvant être liées à des données partagées ont deux FK; l'un utilise le TenantID et les liens vers des données locales, l'autre n'utilise pas TenantID et des liens vers des données partagées. Une contrainte indique que l'un ou l'autre doit être utilisé, pas les deux. C'est probablement l'approche la plus "pure", mais elle semble juste ... moche, mais peut-être pas aussi laide que les autres.

Alors, ma question est en deux parties:

• Y a-t-il des options que je ne l'ai pas pris en compte?
• Est-ce que quelqu'un a eu l'expérience avec ces options et a des commentaires sur les avantages/inconvénients?

Answer 1

Un collègue m'a donné un aperçu qui a bien fonctionné. Au lieu de penser à l'accès du locataire en tant que locataire, pensez-y comme un accès de groupe. Un locataire peut appartenir à plusieurs groupes, y compris son propre groupe spécifié. Les données appartiennent alors à un groupe, éventuellement le groupe spécifique du locataire, ou peut-être un groupe plus général. Ainsi, "Ma banque" appartiendrait au groupe du locataire, "Banque locale" appartiendrait à un groupement régional auquel le locataire aurait accès, et "Banque globale" appartiendrait au groupe "Tout le monde". Cela conserve l'intégrité, FK et ajoute également la possibilité d'avoir des hiérarchies de locataires, pas quelque chose dont j'ai besoin du tout dans mon scénario, mais une belle petite possibilité.

Answer 2

A Citus, nous construisons une base de données multi-locataires en utilisant PostgreSQL. Pour les informations partagées, nous les conservons dans ce que nous appelons "reference" tables, qui sont en effet copiées sur tous les nœuds. Cependant, nous gardons cette synchronisation in-synchronisée et cohérente en utilisant 2PC, et pouvons également créer des relations FK entre les données de référence et les données de non-référence. Vous pouvez trouver plus d'informations here.