Database singolo Vs Database multiplo su SQL Server

Question

Database singolo Vs Database multiplo su SQL Server

#1 da (2 voti)

0

abbiamo un'applicazione web che memorizza le informazioni nel back end SQL 2014. attualmente viene impostato il modo in cui il database centrale memorizza tutte le informazioni chiave per i clienti e quindi abbiamo un database separato per ogni cliente. Ora la struttura delle tabelle per il database di ciascun cliente è la stessa per un particolare prodotto. per esempio. se un cliente1 DB ha tabelle mandorle, arance e DB cliente 2 ha tabelle limone, agrumi la struttura è la stessa tabella è diversa dipende da che tipo di famrs hanno. Queste tabelle appartengono al Prodotto 1 che hanno acquistato. Queste tabelle non hanno alcun riferimento alla chiave dato che avrà dati ridondanti.

In futuro, se acquisteranno il secondo prodotto, la struttura della tabella per il prodotto sarà diversa da quella del prodotto1 ma sarà uguale per ogni database dei clienti.

Attualmente siamo di piccole dimensioni ma ci aspettiamo di crescere molto molto grandi con tutti i tipi di dati spaziali e dati grezzi con immagini, dati GIS ecc. Anche con prodotti diversi che offrono prodotti come prodotto1, prodotto2, prodotto3 ecc.

la domanda è .. Questo buon database è progettato per un futuro riferimento al carico pesante della mano?

Dovrebbe andare avanti per avere un grande database contenente tutte le informazioni?

Anche mantenere il database centrale su SQL e ogni DB cliente mantenere sul platfrom 'Non solo SQL' (MongoDB, Cassendra) sarà un buon approccio?

sql database-design sql-server multitenancy

posta Ankit Shah 10.08.2016 - 22:56

fonte

1 risposta

Leggi altre domande sui tag sql database-design sql-server multitenancy

API REST - Eager che carica le risorse nidificate Come utilizzare l'integrazione delle dipendenze per le applicazioni che sono configurabili all'avvio?

score 2 · Answer 1

Come le arance sono diverse dai limoni? Voglio dire, sono "strutturalmente differenti" come un Product è strutturalmente diverso da Person o da Comment , oppure sono solo forme diverse dello stesso oggetto, come Smartphone e Tablet sono semplicemente differenti forme di un dispositivo?

Nel primo caso, tabelle distinte hanno senso. Nel secondo caso, normalmente ci sarà una tabella ConsumerDevice che memorizzerà entrambe le forme di oggetti. A volte, la distinzione non sarebbe chiara e la struttura potrebbe cambiare nel tempo.

Per quanto riguarda l'unico database per cliente, posso vedere almeno tre ragioni per utilizzare questo approccio:

Se i dati del cliente appartengono al cliente, puoi facilmente fare un dump del database, senza dover filtrare attentamente i dati che appartengono ad altri clienti.
Se hai un'offerta specifica in cui un cliente può ospitare il tuo servizio internamente, questo è il seguente: la migrazione del database dai tuoi server ai clienti diventa molto semplice e non influisce in alcun modo sugli altri clienti .
Puoi aggiornare il prodotto in modo selettivo per alcuni dei tuoi clienti prima di inviare la nuova versione a tutti.

Tuttavia, se fossi in te, ci penserei due volte prima di usare questo approccio. La manutenzione del database potrebbe rapidamente diventare un incubo. Potrebbe funzionare se hai esperienza di DBA che hanno già sperimentato il caso in cui dovevano mantenere centinaia o migliaia di database simili. Altrimenti, evitatelo a tutti i costi. Un'infrastruttura completamente automatizzata è anche un requisito qui: "L'approccio di Remote Desktop / cerchiamo patch rapidamente" è fuori questione qui.