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

Ho più applicazioni alcune che usano dati provenienti dalle stesse fonti. È buona pratica (o quali sono i pro / contro):

• lasciare i dati nei database condivisi da più applicazioni

  1. risparmia spazio poiché è necessario un solo database
  2. complica l'indicizzazione poiché diverse applicazioni hanno esigenze di interrogazione diverse

• importa quotidianamente i dati in database per app

  1. utilizza più spazio in quanto esistono dati duplicati nei database per app
  2. indicizzazione più semplice poiché ogni app può concentrarsi sulle sue esigenze individuali

Potrei aver escluso altri vantaggi / svantaggi, elencare eventuali, anche come viene fatto sul posto di lavoro?

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

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

• Più applicazioni utilizzano lo stesso database, più è probabile che si verifichino colli di bottiglia delle prestazioni e che non sia possibile ridimensionare facilmente il carico come desiderato . I database SQL non si adattano davvero. Puoi acquistare macchine più grandi ma non si adattano bene ai cluster!

• I costi di manutenzione e sviluppo possono aumentare : lo sviluppo è più difficile se un'applicazione deve utilizzare strutture di database che non sono adatte all'attività in corso ma devono essere utilizzate in quanto sono già presenti. È anche probabile che le regolazioni di un'applicazione abbiano effetti collaterali su altre applicazioni ("perché c'è un trigger così inutile ??!" / "Non abbiamo più bisogno di quei dati!"). È già difficile con un database per una singola applicazione, quando gli sviluppatori non conoscono / 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 rispettare le 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 obsoleti o avrebbero dovuto essere modificati prima da un'altra applicazione? Che dire delle diverse applicazioni che lavorano contemporaneamente sulle stesse tabelle?

Rispetto a ciò, le importazioni di dati / i processi ETL sono quasi sempre abbastanza chiari e semplici. Carica i dati tutte le volte che è necessario, lo spazio è economico. Puoi rendere conto della scalabilità per ogni applicazione in modo indipendente, regolare e modificare le strutture quando ne hai bisogno e non ci saranno problemi di concorrenza. Anche gli effetti collaterali possono essere rintracciati molto più facilmente.

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

Una volta ho avuto una situazione simile. Il mio problema era creare 3 applicazioni, una per la gestione dell'inventario, una per la gestione degli acquisti e una per la gestione degli utenti, ovvero i dipendenti. La mia raccomandazione è di non rompere fisicamente i database per applicazione o di 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 i sistemi di inventario che quelli di approvvigionamento utilizzavano le stesse informazioni di merci e articoli di inventario.

Ho creato un database condiviso, in cui ho archiviato le informazioni di utenti e merci. Quindi ho creato un livello di servizio sopra di esso e ho usato quei servizi in altre applicazioni. Per mostrare un elenco di tutti i dipendenti che si trovano ora in azienda, ad esempio, dovevo solo chiamare un metodo dal servizio simile GetOnWorkEmployees().

Ho anche creato un'interfaccia utente comune per l'interazione con utenti e beni che era un'applicazione web separata a sé stante.

Quindi, aggiungendo a ciò che @Falcon ha indicato, penso che tu possa trarre vantaggio dalla centralizzazione della funzionalità comune tra le applicazioni in un database.

Se si prevede che queste applicazioni funzionino con gli stessi dati, ad esempio lo stesso elenco di prodotti e clienti, tenere insieme il database. Non si ottiene nulla separando i database. Questo è puramente un problema "umano": per il server sono solo i byte su un disco. Non importa se i suoi 1 o 100 database. Ma se lo dividi, devi occuparti della sincronizzazione dei dati. I problemi di indicizzazione che sollevi non rappresentano un vero problema: passeresti la stessa quantità di tempo del processore a mantenere gli indici se i db fossero divisi.

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

Può valere o meno la pena compensare nella tua situazione, ma mantenere l'integrità dei dati è più facile con un singolo database. Almeno in MS SQL Server, non è possibile chiave esterna da un database a un altro database. È possibile simulare il comportamento di una chiave esterna con i trigger, ma non è particolarmente elegante.

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

Una volta avevo più siti Web che sono diventati popolari nel tempo. Hanno usato database separati, principalmente perché il provider di hosting ha concesso solo 1 GB di spazio di archiviazione 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.

Così ho ottimizzato la struttura del database e ho compresso le parti rilevanti in questo database centrale, ma ho lasciato fuori tutto il resto.

La mia opinione è in qualche modo collegata ai paradigmi di OOP. Dati simili devono essere archiviati insieme, quindi se si creano applicazioni diverse, è necessario utilizzare database diversi per esse.

Nel caso precedente non è possibile evitare l'uso del db comune, ma ricordare che ho anche tenuto alcuni tavoli separati in un db separato, che non fanno parte delle query comuni.

Inoltre, se li mantieni separati, sarà più facile 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 viene incasinato e sostanzialmente non vuoi esporre la tua app a questo pericolo.

Tutto sommato, è possibile mantenere un database comune per le query comuni, ma conservarne anche uno per ciascuna delle applicazioni.

Puoi approfondire la tua architettura applicativa?

Se il tuo database funziona come un repository di dati senza logica applicativa come trigger o codice pacchetto business, sarebbe meglio avere un unico database e incapsulare funzionalità di livello aziendale per servizi che utilizzano il database per tutte le loro azioni. Se si hanno trigger o codice nello schema del database, ci si troveranno in grossi problemi utilizzando un singolo database che può essere problematico in molti casi.