Devo usare un database per applicazione o condividere un singolo database tra più applicazioni [chiuso]

Lo spazio è economico in questi giorni, quindi consiglierei di utilizzare un database per applicazione.

La condivisione di un database tra più applicazioni presenta alcuni seri svantaggi :

• Più applicazioni usano lo stesso database, più è probabile che lo sia che hai colpito i colli di bottiglia delle prestazioni e che non è in grado di ridimensionare facilmente il file caricare come desiderato . I database SQL non sono davvero scalabili. Puoi acquistare macchine più grandi ma non scalano bene nei cluster!

• I costi di manutenzione e sviluppo possono aumentare : lo sviluppo è più difficile se un'applicazione ha bisogno di usare il database strutture che non sono adatte per l'attività in corso ma devono essere usato come sono già presenti. È anche probabile che gli aggiustamenti di un'applicazione presentino effetti collaterali su altre applicazioni ("perché esiste un trigger non necessario ??!" / "Non abbiamo più bisogno di questi dati!"). È già difficile con un database per una singola applicazione, quando gli sviluppatori non possono / non possono conoscere tutti i casi d'uso.

• L'amministrazione diventa più difficile: quale oggetto appartiene a quale applicazione? Caos in aumento. Dove devo cercare i miei dati? A quale utente è consentito interagire con quali oggetti? Cosa posso concedere a chi?

• Aggiornamento: avrai bisogno di una versione che sia il minimo comune denominatore per tutte le applicazioni che lo utilizzano. Ciò significa che alcune applicazioni non saranno in grado di utilizzare potenti funzionalità. Dovrai attenersi alle versioni precedenti. Aumenta anche un po 'i costi di sviluppo.

• Concorrenza: puoi davvero essere sicuro che non ci siano dipendenze cronologiche tra i processi? Cosa succede se un'applicazione modifica i dati che sono obsoleti o dovrebbero essere stati modificati da un'altra applicazione prima? Che ne è delle altre applicazioni che lavorano contemporaneamente sulle stesse tabelle?

A confronto, i processi di importazione dei dati / ETL sono quasi sempre semplici e immediati. Carica i dati tutte le volte che vuoi, lo spazio è economico. È possibile tenere conto della scalabilità per ciascuna applicazione in modo indipendente, regolare e modificare le strutture in base alle proprie esigenze e non ci saranno problemi di concorrenza. Gli effetti collaterali possono essere tracciati anche molto più facilmente.

Modifica Vorrei sottolineare, tuttavia, che come @Saeed ha menzionato, se è possibile incapsulare le manipolazioni di dati in un servizio che è comunemente disponibile, è più facile condividere un database con più applicazioni. Finché non hai bisogno di un accesso raw, questo è un ottimo approccio.

Ho avuto una situazione simile una volta. Il mio problema era di creare 3 applicazioni, una per la gestione delle scorte, una per la gestione degli approvvigionamenti e una per la gestione degli utenti, ovvero i dipendenti. La mia raccomandazione è di non rompere fisicamente i database per applicazione o unirli fisicamente per applicazione. Piuttosto, la separazione logica IMHO funziona meglio.

Ad esempio, tutte e 3 le applicazioni necessarie per lavorare con le informazioni dei dipendenti. Sia l'inventario che i sistemi di approvvigionamento utilizzavano le stesse informazioni di merci e articoli di magazzino.

Ho creato un database condiviso, nel quale ho memorizzato le informazioni di utenti e merci. Poi ho creato un livello di servizio su di esso e ho usato quei servizi in altre applicazioni. Per mostrare un elenco di tutti i dipendenti che sono ora in azienda, ad esempio, ho solo dovuto chiamare un metodo dal servizio come GetOnWorkEmployees() .

Ho anche creato un'interfaccia utente comune per interagire con utenti e merci che era un'applicazione web separata a parte.

Quindi, aggiungendo a ciò che @Falcon ha indicato, penso che si possa trarre beneficio dalla centralizzazione delle funzionalità comuni tra le applicazioni in un database.

Se queste applicazioni hanno lo scopo di funzionare con gli stessi dati, ad esempio lo stesso elenco di prodotti e clienti, quindi mantenere il database insieme. Non ottieni nulla separando i database. Questo è puramente un problema "umano" - al server è solo un byte su un disco. Non importa se i suoi 1 o 100 database. Ma se lo dividi, devi gestire la sincronizzazione dei dati. I problemi di indicizzazione che si presentano non rappresentano un problema reale: si impiegherebbe la stessa quantità di tempo di processore a mantenere gli indici se i db fossero suddivisi.

Se le prestazioni iniziano a diventare un problema, replicate il db su più server per bilanciare le cose.

Potrebbe valere la pena o meno del compromesso nella tua situazione, ma mantenere l'integrità dei dati è più semplice con un singolo database. Almeno in MS SQL Server, non è possibile la chiave esterna da un database a un altro database. Puoi simulare il comportamento delle chiavi esterne con i trigger, ma non è particolarmente elegante.

Inoltre, la creazione di copie locali dei dati può essere pericolosa quando le scritture entrano in gioco. Se AppA e AppB hanno entrambi una copia di alcuni dati condivisi e AppA lo aggiorna, AppB avrà ancora i vecchi dati. In alternativa, dovrai impostare i trigger per mantenere i dati sincronizzati.

Una volta ho avuto più siti web che sono diventati popolari nel tempo. Hanno utilizzato database separati, soprattutto perché il provider di hosting ha consentito solo uno spazio di archiviazione di 1 GB ciascuno. Ma! Non appena ho rilasciato un servizio che includeva tutti questi siti web, ho iniziato a dover effettuare transazioni tra questi siti Web e il modo più conveniente per farlo è sicuramente spostare tutto in un unico grande database.

Quindi ho ottimizzato la struttura del database e ho spremuto le parti rilevanti in questo database centrale, ma ho lasciato tutto fuori.

La mia opinione è in qualche modo correlata ai paradigmi di OOP. Dati simili devono essere archiviati insieme, quindi se costruisci applicazioni diverse, dovresti usare diversi database per loro.

Nel caso precedente non è possibile evitare il db comune, ma ricorda che ho anche tenuto alcuni tavoli separati in un db separato, che non fa parte delle query comuni.

Inoltre, se li tenete separati, saranno più facili da eseguire il backup, ci saranno meno possibilità di perdita di dati. Se qualcosa va storto e le applicazioni interferiscono l'una con l'altra, il database diventa incasinato, e fondamentalmente non vuoi esporre la tua app a questo pericolo.

Tutto sommato, puoi mantenere un database comune per le query comuni, ma anche mantenerne uno per ciascuna delle tue applicazioni.

Puoi approfondire la tua architettura di applicazione?

Se il database funziona come un repository di dati senza logica applicativa come trigger o codice del pacchetto aziendale, sarebbe meglio disporre di un singolo database e incapsulare funzionalità a livello di business per i servizi che utilizzano il database per tutte le loro azioni. Se si dispone di trigger o codice nello schema del database, si avrà un grosso problema utilizzando un singolo database che può essere problematico in molti casi.