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


33

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?


1
Come definisci l'applicazione: build separate, sviluppatori diversi?
JeffO,

La condivisione del database trasforma l'intero database in un'API pubblica grande e disordinata. E mancano tutte le astrazioni che potresti avere creato nella prima applicazione.
Patrick,

Le prestazioni sono un problema? Con abbastanza record che dissuaderebbero uno da un unico grande database. Lo spazio è economico.
Rig

Risposte:


41

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.


Quando utilizzo un servizio per il db condiviso secondo la risposta di @ Saeed, non ho ancora la preoccupazione che più app non abbiano esigenze diverse e che richiedano una vasta gamma di indici nel database?
Laz

2
@Laz: probabilmente dipende dai casi d'uso e dai requisiti.
Falcon,

2
Uno dei fondamenti della progettazione di database relazionali non ha dati duplicati. Avere database diversi che contengono sovrapposizioni degli stessi dati richiede solo problemi.
Pieter B,

Pieter B: Presumo che tu non abbia mai lavorato in ambienti aziendali, come per le grandi aziende. Avere un database con molte applicazioni diverse e diversi team di sviluppo richiede solo problemi e alla fine può bloccare lo sviluppo. Detto questo, non c'è mai un imho scelta in bianco e nero.
Falcon,

@PieterB: più applicazioni che leggono e scrivono gli stessi dati sono una buona indicazione che dovresti considerare un livello di servizio rispetto al quale tutte le applicazioni possono fare richieste. D'altra parte, se sono abbastanza diversi da non poter fattorizzare un servizio comune, allora sono abbastanza diversi da richiedere tabelle / database separati.
Dan Lyons,

23

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.


3
+1 per separazione logica e suggerimento di un'architettura pulita. La SOA rende queste cose davvero più facili
Falcon,

Sicuramente +1 per l'organizzazione logica. Lascia che i dati siano raggruppati per ottimizzare l'equilibrio tra accoppiamento e coesione e quindi le applicazioni possono immergersi in qualsiasi database di cui hanno bisogno per svolgere il proprio lavoro.
Joel Brown,

9

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.


3

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.


+1: è abbastanza facile mappare più applicazioni su un singolo database.
Kevin Cline,

0

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.


0

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.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.