Database multipli V / s singoli

Ho creato questa app web (php & mysql) che memorizza informazioni per varie organizzazioni (attualmente circa 20 clienti).

Lo scenario attuale memorizza le informazioni relative al client in singoli database, quindi ci sono 20 database client e 1 database master.

Uno dei principali vantaggi qui è che quando ogni db del client è isolato, la numerazione degli artefatti del client (report, audit) ecc. Viene sequenziata; dare ai nostri clienti un senso di sicurezza.

Ogni DB ha circa 15 tabelle e la maggior parte delle righe in una tabella sono circa 2000. Si prevede che questo verrà sommato fino a 5000 record, al massimo.

Gestire una singola modifica a livello di db significa cambiare 20 database, ma nel raro caso in cui ho bisogno di apportare una tale modifica, utilizzo uno script che lo fa in una singola chiamata di funzione.

Siamo in un accordo di hosting condiviso e il nostro ISP ci fornisce un numero limitato. di database; ed è quello che mi ha portato a pensare in termini di centralizzazione del database; in modo che TUTTI i dati del client possano essere archiviati nel database principale.

Naturalmente, alcune importanti questioni che emergono sono:

un. Mantenimento della sequenza di artefatti, (questo potrebbe essere risolto creando una chiave di riferimento aggiuntiva) b. Velocità e prestazioni (nel qual caso posso creare indici per velocizzare le cose) c. Sicurezza: questo verrà gestito come ogni query che recupera le informazioni sul client. seguirà anche il loro client_id

In futuro, potremmo aver bisogno di considerare il confronto di set di dati di un'organizzazione con un'altra, ma credo che ciò possa essere realizzato anche su un db centralizzato. Sono un po 'propenso (per motivi di prestazioni e manutenibilità) a passare a un database centralizzato.

Pensi che passare a un database centralizzato abbia più senso che restare come siamo (su singoli database)?

Grazie per il tuo consiglio.

Esistono rischi e benefici ereditari per entrambi i sistemi. Ho lavorato per una società finanziaria che supportava circa 40 clienti (banche nazionali) su 1 database. Abbiamo quindi acquistato un'altra società che vendeva software simile e che era andato con 1 database per client. Alla fine, la società è fallita e abbiamo dovuto esportare tutti i dati degli utenti. Ecco cosa hanno trovato e trovato le persone con cui ho lavorato:

Pro di DB singolo:

1. Aggiornamenti software e correzioni di bug sono più facili.
2. Facile da gestire e riferire su tutti i dati del cliente.
3. L'aggiornamento dei dati diventa più semplice.
4. Facile da creare funzionalità modulare che 1 client desidera, disattivarlo per gli altri client, quindi attivarlo quando lo desiderano in futuro.

Contro di DB singolo:

1. Integrità dei dati - Abbiamo avuto 2 o 3 casi in cui gli utenti di 1 banca hanno visto i dati di un'altra banca. Questo è stato un incubo. Soprattutto perché gli utenti del sito non erano solo i dipendenti della banca, ma i conti reali che trattengono i clienti della banca! Questo è di gran lunga il problema più grande con 1 database
2. Esportazione dei dati del cliente -Quando dovevamo farlo di solito non era un grosso problema. Si finisce con 1 tabella che contiene tutti i client e si esce da quella tabella per ottenere i dati specifici del client.

Pro di DB multipli:

1. Non vi è alcun rischio di contaminazione o violazione dei dati tra client
2. L'esportazione dei dati di un cliente è semplicissima.

Contro di DB multipli:

1. Aggiornamenti e correzioni di bug - Questo è stato il vero incubo. Quando hai 20 client su 20 database diversi, ti imbatti rapidamente nel caso in cui 1 client voglia correggere un bug e un altro pensa che il bug sia una funzionalità o non voglia rischiare l'aggiornamento. Inoltre, avrai casi in cui 1 client desidera un miglioramento del cambio di gioco, ma gli altri client no. Quando ciò accade, i database inizieranno a divergere. All'improvviso dovrai aggiornare i client 1-15 con 1 script 16-19 con un altro e 20 con un terzo. Abbiamo visto questo diventare un tale problema che una correzione di bug richiederebbe da 15 a 20 volte di più per l'azienda che abbiamo acquistato rispetto a noi perché hanno dovuto eseguire tutti i test per ogni cliente e gestire ogni codice speciale di ciascun cliente. In effetti, avevano bisogno di una nuova persona di supporto per ogni nuovo cliente,
2. Gestione DB - Quando si arriva a un gran numero di client, la gestione di tutti i database diventa una vera seccatura. Avrai sicuramente bisogno di più tempo DBA per gestirli.

Alla fine la mia raccomandazione di aver visto e fatto entrambi è quella di avere "disciplina"! Penso che la scelta multi-db sia leggermente migliore perché ti protegge ma non puoi mai permettere ai tuoi clienti di fare una scelta che ti fa aggiungere funzionalità solo a loro o ti metterai sulla strada del fallimento.

Avrei database separato per client separati. Un cliente potrebbe richiederlo per motivi di sicurezza, ovvero solo il suo sito ha accesso ai propri dati. Significa anche che se un cliente desidera spostare i propri dati, sarà molto più facile da gestire.

Significa anche che se c'è un problema con il database di un client, questo non influisce su tutti gli altri.

Se si desidera confrontare i dati tra i client, è necessario farlo separatamente.

Se stai esaurendo i database che puoi avere, forse dovresti prendere in considerazione la possibilità di cambiare il tuo provider host.

L'unico motivo per cui non avrei un singolo database per ogni client è se hai 100 o 1000 di client / database. Questo potrebbe diventare davvero peloso da gestire, incluso apportare modifiche al database o fare qualcosa in tutti i database. Le azioni che si verificano su un gran numero di database multipli potrebbero anche essere lente in quanto è necessario aprire (e quindi chiudere) così tante tabelle.

Ma a parte questo caso, penso che più database siano migliori.

Un vantaggio, che può non essere importante ma può essere utile, è che ogni client ottiene i propri ID sequenziali (invece di saltare un gruppo perché un altro client ha aggiunto record).

Inoltre, più database consentono che le tabelle secondarie (come il tipo di telefono) siano facilmente personalizzabili per client senza la necessità di un ID record padre anche in queste tabelle.

Prima il sequenziamento del manufatto. Presumo che tu stia usando chiavi primarie intere per fornire questo. In realtà dovresti avere una colonna "numero artefatto" separata. I PK dovrebbero essere PK e nient'altro. La gente parla di "chiavi naturali" e simili e io rabbrividisco. Ogni volta che fai affidamento sul PK per essere più di un identificatore, torna a morderti. Se vuoi conoscere la sequenza di qualcosa, archivia una data o un numero progressivo.

Penso che nel tuo caso la gestione della configurazione ti porterebbe a un singolo database. Guarda quanto ti costa in tempo per mantenere e aggiornare i database. Quali sono i costi associati a ciascuna versione del software? Pensa anche al costo quando ottieni un nuovo cliente e devi creare un DB e configurare l'app per esso. Qualunque cosa può essere automatizzata, la domanda è: ne varrà la pena quando avrai 100 database?

Lungo la strada, è più facile ridimensionare (partizionamento, hardware, sharding ecc.) Un singolo database piuttosto che fare lo stesso per 100 database.

Penso che gli altri poster abbiano espresso alcuni punti eccellenti, quindi non li supererò.

Per aggiungere ai pro / contro elencati fino ad ora:

Pro di più database:

1. I problemi di blocco sono evitati; abbiamo database in cui i client possono attivare modifiche DDL su alcune delle tabelle. Per le tabelle più grandi (record> 2m) questo blocca la tabella per un tempo considerevole. Le uniche persone svantaggiate sono i propri utenti, quindi questo è abbastanza accettabile.

2. Flessibilità: alcuni clienti hanno desideri specifici riguardo ai dati che desiderano archiviare; il multi-database ci ha permesso di modificare in modo specifico il loro database, senza dover ingombrare il modello di dati per gli altri client.

Contro:

1. Con maggiore: Partecipare ad altri tavoli è molto più complicato. Abbiamo un database principale che contiene la maggior parte dei metadati. Gli utenti del database specifici del client non hanno accesso a questo database, quindi tutti i join tra le tabelle in quel database e quello specifico del client vengono gestiti nell'applicazione anziché nel database. È possibile risolvere questo problema dando agli utenti specifici del client l'accesso al database principale, ma l'app potrebbe / potrebbe perdere di nuovo informazioni.

Buona fortuna nella scelta!

So che hai già scelto una risposta, ma sembra che ci sia un'altra soluzione che non è stata suggerita:

Sposta tutto in un database, ma crea tabelle per ogni cliente, usando un prefisso, come questo:

initec_contacts_tbl
initec_accounts_tbl
initec_personel_tbl
...
masterco_contacts_tbl
masterco_accounts_tbl
masterco_personel_tbl

È un po 'il migliore dei due mondi.

• È molto facile migrare dalla configurazione corrente a quella nuova.
• Puoi creare 1 utente per client e limitare i suoi privilegi alle tabelle della sua azienda e nient'altro
• È possibile creare un superutente e aggregare facilmente i dati se è necessario.
• Utilizzare solo un database