Ogni app deve avere il proprio database o le piccole app devono essere unite in un'unica? [duplicare]

2

Abbiamo un sacco di app di piccole e medie dimensioni, ognuna delle quali ha il proprio database (MSSQL Server). È stato suggerito di consaldare i database "correlati" in una quantità più piccola di database più grandi.

Non condividono in modo particolare molti dati, sarebbero solo in un gruppo aziendale simile. Ad esempio, utilizzando un database "Finanze" per conservare le tabelle e le procedure per le app finanziarie.

Sarebbe opportuno utilizzare uno schema diverso per ogni app, ad es.

App1.SomeTable
App1.SomeOtherTable
AppTwo.SomeTable

Quali sono i pro e i contro di questo approccio? A cosa devo fare attenzione?

    
posta King 20.06.2012 - 18:59
fonte

3 risposte

5

A rischio di affermare l'ovvio, in generale, se condividi i DB, stai accoppiando le applicazioni e rendendo le modifiche ai DB più "globali". Nella maggior parte dei casi, questa è probabilmente una cattiva idea, per gli stessi motivi per cui le variabili a più ampio spettro sono generalmente una cattiva idea. Tuttavia, se vi è uno sforzo significativo nel mantenimento o nell'ottimizzazione del DB, allora potresti avere alcuni guadagni (ad esempio, se il tuo DBA ottimizza il DB per ottenere prestazioni migliori, tutti ottiene la spinta, o se spendi una quantità significativa di controllo e pulizia dei dati).

    
risposta data 21.06.2012 - 00:49
fonte
1

Questo drastico cambiamento dovrebbe essere fatto per risolvere un problema. Ci sono pro e contro di più / più vs singoli / meno database. Dipende dai problemi che stai cercando di risolvere.

I tuoi sviluppatori non riescono a trovare dove sono i dati? Potrebbe essere più semplice lavorare nell'app Finance sapendo che esiste un singolo db Finanza.

È davvero difficile fare riferimento a due tabelle in una query da diversi database?

Backup : il ripristino a livello di database è piuttosto semplice. Il minor numero di tavoli e altre parti più facile diventa. Sì, puoi suddividere grandi database in più file. Sta solo rendendo più difficile mantenere un database di sviluppo se devi trasferire file di grandi dimensioni, soprattutto quando ti serve solo una sezione specifica.

Altri server : è più facile spostare un database su un altro server. È molto più difficile mettere un database su diversi componenti hardware.

Non so quale sia la tua situazione, ma sembra che non ci sia alcuna giustificazione per un database. Se si verificano problemi, riconsiderare.

    
risposta data 21.06.2012 - 01:18
fonte
1

Integrare la fonte delle informazioni è una buona cosa da cercare. Di fatto, le organizzazioni spendono milioni per integrare i loro disparati sistemi di supporto decisionale e sistemi operativi. È necessario determinare:

1-Quali sono i dati condivisi?

2-Quanto spesso cambiano questi dati?

3-Quanto è grande il volume di questi dati?

4-I dati possono essere reinseriti manualmente o sono troppo lunghi e / o soggetti a errori?

5-Quanto sono sensibili i dati condivisi?

6-Qual è il costo dell'automazione?

In alcuni casi, specialmente con le piccole imprese, il numero di transazioni non è così grande e probabilmente ci vorrebbe meno di 1 ora per inserire le informazioni manualmente. Il costo di questo sforzo può essere misurato in dollari rispetto al costo di automazione proposto.

Potresti voler usare una matrice simile all'esempio grezzo di seguito (so che non è né accurata né completa!) per mostrare i dati condivisi e come questi dati sono condivisi. Il lato sinistro rappresenta la tabella e le intestazioni delle colonne orizzontali rappresentano i diversi sistemi. Esiste una tecnica di analisi chiamata Clustering Analysis che può essere utilizzata per mostrare i confini del sistema, ma non ho un riferimento elettronico per questo (è vecchio!).

    
risposta data 21.06.2012 - 01:16
fonte

Leggi altre domande sui tag