Come utilizzare correttamente un database contenente tabelle comuni in un sistema multi-applicazione?

Mi piace l'opzione 1. Le tue app ignorano quindi il loro schema di persistenza sottostante e la gestione della persistenza viene eseguita dall'API (o livelli sotto / all'interno).

Un percorso comune sarebbe la tua opzione # 1, con un pattern di repository che ha un'interfaccia come "get this", "get that", e l'implementazione del repository si occupa di estrarre le informazioni da (e salvare le informazioni in) database corretto.

In alternativa, un'API separata per ogni app, in cui ogni API ha un repository da qualche parte sotto che fa la stessa cosa.

Eviterei che le app "parlino" direttamente con il database come indicato nelle opzioni 2 e 3.

Ricorda che (in genere) ogni componente non dovrebbe in genere riguardare i dettagli dei servizi sottostanti.

In generale, più i tuoi servizi / livelli sono separati, più è facile mantenerli a lungo termine, al costo di una configurazione iniziale più complessa. D'altra parte, iniziare con un'architettura molto semplice può essere estremamente difficile da trattare in seguito, quindi se c'è una qualche longevità attesa nel progetto, sono molto più adatto ad andare con l'investimento in architettura.

Ci sono molte varianti su di esso (e se stai facendo qualcosa come microservizi sei in un regno molto diverso), ma ecco una rapida visione che ottiene il punto di partenza:

Sto vedendo la necessità di tabelle comuni, che poi sono esplose in più database. Questo mi preoccuperebbe.

Separare il livello dell'applicazione in più applicazioni può essere un buon punto di partenza, ma separare i database non è sicuramente il primo passo.

Crea 1 database. Le tabelle "comuni" andrebbero in uno schema "comune". Ogni applicazione otterrebbe il proprio schema e può contenere riferimenti a chiavi esterne a tabelle nello schema comune.

Da lì sei libero di suddividere il livello applicazione in tutte le app e le API che ritieni più idonee.

Se le prestazioni del database sono un problema, iniziare con un'architettura server che consenta la condivisione del database. Ciò può aiutare a distribuire il carico e, poiché vengono utilizzati più server, è possibile aggiornare l'hardware senza un "ecosostenimento" coordinato delle applicazioni da un nuovo database aggiornato.

Inizia con 1 database. Schemi separati. Dividi il tuo livello di applicazione in tutti i livelli, API e micro servizi che ritieni adatti. È molto più semplice rifattorizzare il codice che ristrutturare i dati, in particolare i dati in server di database separati.

Quando si estraggono report troppo lenti, è ora di aggiungere un "database di report". Dopo tutto, i rapporti trimestrali non hanno bisogno di dati aggiornati al secondo. La coerenza finale va bene per questo.

Quindi fondamentalmente le opzioni 1-3 sembrano buone, tranne la parte del database. Farli puntare tutti allo stesso DB. Quindi scegli qualsiasi opzione che ti piace.

Aggiornamenti in risposta ai commenti:

SegFaultDev ha commentato:

With mySQL, every schema is actually a Database, as they are synonymous ( at least that is my understanding of it).

Penso che il punto principale sia quello di consentire l'integrità referenziale tra database / schemi / raccolte di tabelle all'inizio. Rompila solo in sistemi completamente separati se devi assolutamente. MySQL non dovrebbe avere un problema con questo.

È del tutto perfetto rompere il livello delle applicazioni in più sistemi (applicazioni web, web API, micro-servizi), ma con l'architettura generale avrai ancora più tempo a disposizione se il tuo meccanismo di archiviazione dei dati è un'unità coesa, sia "schemi" in Oracle o "database" in MySQL.