multitenancy con alcuni dati condivisi

Vuoi un singolo database, un unico archivio di file.

Più database sono solo la strada da percorrere se hai un'app che non è progettata per la multitenancy e non è fattibile adattarla per utilizzare un singolo database.

Se hai un'entità logica sparsa su più di un database, il database non sarà in grado di rafforzare l'integrità e dovrai affrontare i problemi causati da questo - e questo è solo uno dei tanti problemi che avrai .

Avere un singolo database per un'app multi-tenant non è un problema quando si progetta l'app da zero - richiede sicuramente più lavoro per isolare davvero i diversi tennant [cioè tutte le tue domande avranno bisogno di una condizione cliente = xxx, e non puoi dimenticartene], ma è certamente qualcosa di meno fastidioso che avere più database.

Una volta che hai un singolo database, è solo una questione di design dello schema e relazioni n-m (cioè 1 documento può appartenere a n utenti, 1 utente può avere m documenti).

Se si dispone di uno schema normalizzato, la duplicazione dei dati non sarà presente, per definizione:)

Dovrai evitare di duplicare i file e gestire i meccanismi di blocco e le risoluzioni dei conflitti come risultato. Puoi seguire un modello in cui i diritti di modifica sono condivisi su un file anziché duplicare il file che deve essere modificato da un'altra parte.

La condivisione dei diritti di modifica può essere migliorata con la collaborazione consentendo a più utenti di modificare lo stesso documento nello stesso momento (se l'app ha tale funzione) e aiuta gli utenti a evitare di sovrascrivere le modifiche reciproche. È possibile evitare il problema di sovrascrittura mantenendo ovviamente una cronologia di salvataggi, ma nella mia esperienza, un utente potrebbe non notare che è stato appena effettuato un aggiornamento a un documento su cui stava lavorando o caricato, a meno che l'interfaccia utente non lo faccia risaltare.