Pro / Contro dell'utilizzo di più database rispetto all'utilizzo di un singolo database

Stavo lavorando a un nuovo progetto che ha l'obbligo di utilizzare 7 database, sostenendo che prestazioni, stabilità, ottimizzazione sono implementate più facilmente.

Anche se non sono d'accordo, ho problemi a raccogliere buoni argomenti per utilizzare un singolo database (suddividere le tabelle in domini logici).

Un argomento che ho finora è l'integrità dei dati (non riesco a usare chiavi esterne tra i database).

Quali sono i buoni pro / contro per l'utilizzo di un database singolo o multiplo?

[riassunto finora]

Argomenti contro più database:

• Perdita di integrità dei dati (impossibile utilizzare chiavi esterne nei database)

• Perdere l'integrità del ripristino

• Guadagnare complessità (utenti / ruoli db)

• Il server / database di piccole probabilità diminuirà

soluzioni:

• Usa gli schemi per separare i domini.

• POC: utilizzare i dati fittizi per dimostrare il punto nei piani di esecuzione del 7/1 db

Nessuna prestazione, stabilità, ottimizzazione sono vere. Qualcuno ha un argomento solido o un articolo di riferimento perché questi sarebbero veri?

Le risorse non sono allocate in un database: l'istanza di SQL Server bilancia le risorse in modo che non faccia alcuna differenza

Hai perso:

• integrità dei dati
• ripristinare l'integrità (i dati in DB7 saranno successivamente DB1)

Ottieni complessità:

• la sicurezza (utenti, ruoli ecc.) deve essere presente in tutti i database
• avrai alcuni dati che non rientrano bene in 1 database

Opzioni:

• la divisione di un database su dischi separati può essere eseguita con filegroup
• usa gli schemi per separare logicamente i dati (sulla base di altre risposte)

Buoni motivi per creare database separati sarebbero supportare diversi requisiti di disponibilità o semplificare l'amministrazione. Ad esempio, se i database richiedono pianificazioni di backup molto diverse o modelli di ripristino diversi. Un altro motivo potrebbe essere se si desidera eseguirli su istanze diverse.

Non sono disponibili ottimizzazioni delle prestazioni con più database che non è possibile ottenere anche con un database. Puoi fornire maggiori dettagli su cosa intendi per "prestazioni, stabilità, ottimizzazione"?

Se stai dopo aver diviso i dati per dominio logico puoi sempre guardare usando schemi all'interno di SQL2008 (andando via dal default di dbo.) Ma anche questo è doloroso e può causare problemi con OR / M che non si aspettano un non schema standard.

Sono stato in grado di raccogliere dati da più di un database ed è doloroso e tutt'altro che ad alte prestazioni. Si finisce per memorizzare nella cache i dati o almeno usando i trucchi per mantenere la velocità.

Come test, crea 7 database fittizi. Crea una query che richiede dati contemporaneamente da tutti e 7, o almeno un buon numero di essi.

Quindi confrontare i piani di esecuzione! Penso che vincerai il tuo caso proprio lì.

Esperimento di pensiero: invece di dividere il database in sette pezzi, dividerlo invece in 7.000 pezzi. Qual è la probabilità che un errore hardware abbia un impatto sulla tua applicazione? Se esiste una probabilità dello 0,1% che un determinato server muoia in un determinato giorno, le tue possibilità sono migliori o peggiori di essere colpite da un guasto hardware quando aumenti il ​​numero di macchine da cui dipendi?

Penso che sia importante dividere la nozione di "database" in due parti: lo schema e i dati rispetto all'hardware utilizzato per servire i dati.

Rompere il database su più macchine non è utile per i molti motivi spiegati dalle altre risposte in questo argomento.

Se hai intenzione di utilizzare più macchine per affidabilità e prestazioni ottimizzate, forse puoi strutturarle in modo da disporre di un server master con più macchine warm / hot standby che potrebbero anche essere utilizzate per distribuire query tra loro. In questo modo, se si verifica un errore in una macchina, non si perdono dati e, nel peggiore dei casi, è necessario riavviare una query. Certo, è più complesso di così, ma si applicano le basi.

Concordo con un DB e utilizzo invece le opzioni di file e schema.

Ci sono casi limite in cui ha senso dividere in più pezzi.

Configurazione dell'ambiente di applicazione (sviluppo, test, prod), come server FTP, percorsi di file di esportazione, ecc ..., roba che si desidera archiviare per server e non sovrascrivere su un ripristino.

Anche come modo per isolare le modifiche alla procedura specifica del cliente.

Ma questi sono problemi di supporto e non di prestazioni.