L'applicazione su cui lavoro utilizza set nidificati 1 per rappresentare strutture ad albero all'interno del nostro database .
Abbiamo bisogno di espandere una particolare area di controllo degli accessi per supportare più client che non dovrebbero essere in grado di vedere le informazioni di altri client (ovvero multi-tenancy).
Abbiamo preferito l'approccio dell'insieme nidificato rispetto all'approccio più "ingenuo" per una serie di motivi, riassunti in questa presentazione sulla diapositiva 69 .
A prima vista, nulla all'interno di una struttura di serie annidata sembra essere un problema che impedirebbe il suo utilizzo all'interno di un ambiente multi-tenant. Tuttavia, uno dei problemi con gli insiemi nidificati è il numero di aggiornamenti richiesti per l'aggiunta o la rimozione dei nodi foglia. Ad esempio, tutte le voci a destra del nodo foglia inserito finiscono per richiedere l'aggiornamento dei valori sinistro e destro.
Per la tabella in questione, rimarrà sempre relativamente piccola (~ 5-10k righe, in alto) anche con più inquilini.
Abbiamo anche clienti che vorranno ulteriori restrizioni di accesso oltre a quelle fornite dagli ACL, espresse attraverso un albero dei set nidificati.
Per soddisfare le restrizioni di accesso del client e anche per risolvere potenziali problemi di aggiornamento del database, stiamo considerando l'aggiunta di un campo ClientId alla nostra tabella dei set nidificati. L'idea è che gli aggiornamenti dell'albero di un cliente non debbano influire sugli alberi di altri client. Allo stesso modo, avremo un blocco rigido sul posto se il Cliente A tenta di accedere inavvertitamente ai dati del Cliente B perché il campo Client non corrisponderà.
| RowId | ClientId | Left | Right | Foo... | Bar... | |-------|----------|------|-------|--------|--------| | 3 | 10 | 1 | 42 | ... | ... | | 5 | 20 | 1 | 69 | ... | |
Una delle mie complicazioni è che ho un gruppo di utenti (chiamiamoli "ClientId 0") che eseguiranno azioni per gli altri client (come "Client 10", "Client 20"). E le azioni eseguite da "Client 0" devono essere visibili / utilizzabili dal cliente per il quale hanno eseguito l'azione. Quindi "Cliente 0" deve creare cose che riceveranno un ClientId diverso. 2
Questo approccio sembra essere valido, o cosa dovrei esaminare per capire se reggerà come ho spiegato sopra?
In alternativa, esiste una struttura dati superiore per rappresentare informazioni multi-tenant e gerarchiche?
1 Vedi anche questo slidedeck a partire dalla diapositiva 53 per ulteriori dettagli sull'implementazione di una struttura ad albero dell'insieme annidato.
2 Il mio approccio di lavoro per risolvere questo è quello di estrarre ClientId dal nodo su cui lavora il Client 0 e assegnare ClientId del nodo al nodo appena creato.