Vorresti di aver utilizzato database separati:
- Se mai vuoi concedere autorizzazioni ai database stessi a client o superutenti.
- Se mai vuoi ripristinare il database di un solo cliente senza influire sui dati degli altri.
- Se ci sono problemi di regolamentazione che regolano i tuoi dati e violazioni dei dati e scopri tardivamente che queste normative possono essere soddisfatte solo disponendo di database separati. (Aggiornamento:poco più di 4 anni dopo la stesura di questa risposta, è entrato in vigore il GDPR)
- Se desideri spostare facilmente i dati dei tuoi clienti su più server di database o in altro modo aumentare o spostare clienti più grandi/più importanti su hardware diverso. In un'altra parte del mondo.
- Se mai desideri archiviare e rimuovere facilmente i vecchi dati dei clienti.
- Se ai tuoi clienti interessa che i loro dati vengano messi in silo e scoprono che hai fatto diversamente.
- Se i tuoi dati sono stati citati in giudizio ed è difficile estrarre i dati di un solo cliente, oppure la citazione è eccessivamente ampia e devi produrre l'intero database anziché solo i dati per un cliente.
- Quando ti dimentichi di mantenere la vigilanza e solo una query scivola attraverso che non includeva
AND CustomerID = @CustomerID. Suggerimento:utilizzare uno strumento di autorizzazione tramite script, o schemi, o racchiudere tutte le tabelle con viste che includonoWHERE CustomerID = SomeUserReturningFunction(), o una combinazione di questi. - Quando ottieni autorizzazioni errate a livello di applicazione e i dati dei clienti vengono esposti al cliente sbagliato.
- Quando desideri avere diversi livelli di protezione di backup e ripristino per client diversi.
- Una volta che ti rendi conto che la creazione di un'infrastruttura per creare, fornire, configurare, distribuire e in altro modo avviare/disattivare nuovi database vale l'investimento perché ti obbliga a diventare bravo.
- Quando non consenti la possibilità che alcune classi di persone abbiano bisogno di accedere ai dati di più clienti e hai bisogno di un livello di astrazione sopra
CustomerperchéWHERE CustomerID = @CustomerIDnon lo taglierò ora. - Quando gli hacker prendono di mira i tuoi siti o sistemi e tu hai reso loro facile ottenere tutti i dati di tutti i tuoi clienti in un colpo solo dopo aver ottenuto le credenziali di amministratore in uno solo banca dati.
- Quando il backup del database impiega 5 ore per essere eseguito e poi non riesce.
- Quando devi ottenere l'edizione Enterprise del tuo DBMS in modo da poter eseguire backup compressi in modo che la copia del file di backup in rete richieda meno di 5 ore di più .
- Quando devi ripristinare l'intero database ogni giorno su un server di prova che richiede 5 ore ed eseguire script di convalida che richiedono 2 ore per essere completati.
- Quando solo pochi dei tuoi clienti hanno bisogno della replica e devi applicarla a tutti i tuoi clienti invece che solo a quei pochi.
- Quando vuoi assumere un cliente governativo e scoprire che ti richiedono di utilizzare un server e un database separati, ma il tuo ecosistema è stato costruito attorno a un unico server e database ed è semplicemente troppo difficile o richiederà troppo tempo per cambiarlo .
Sarai felice di aver utilizzato database separati:
- Quando un'implementazione pilota su un cliente esplode completamente e gli altri 999 clienti rimangono completamente inalterati. E puoi ripristinare dal backup per risolvere il problema.
- Quando uno dei backup del database non riesce e puoi correggere solo quello in 25 minuti invece di ricominciare l'intero processo di 10 ore da capo.
Vorresti di aver utilizzato un unico database:
- Quando scopri un bug che interessa tutti i 1000 client e distribuire la correzione a 1000 database è difficile.
- Quando ottieni autorizzazioni errate a livello di database e i dati dei clienti vengono esposti al cliente sbagliato.
- Quando non consenti la possibilità che alcune classi di persone abbiano bisogno di accedere a un sottoinsieme di tutti i database (forse due clienti si uniscono).
- Quando non pensavi quanto sarebbe stato difficile unire due diversi database di dati.
- Quando hai unito due diversi database di dati e ti rendi conto che uno era quello sbagliato e non avevi pianificato il ripristino da questo scenario.
- Quando provi a superare i 32.767 clienti/database su un singolo server e scopri che questo è il massimo in SQL Server 2012.
- Quando ti rendi conto che la gestione di oltre 1.000 database è un incubo più grande di quanto tu abbia mai immaginato.
- Quando ti rendi conto che non puoi inserire un nuovo cliente semplicemente aggiungendo alcuni dati in una tabella e devi eseguire una serie di script complicati e spaventosi per creare, popolare e impostare i permessi su un nuovo database.
- Quando devi eseguire 1000 backup di database ogni giorno, assicurati che tutti abbiano esito positivo, copiali sulla rete, ripristinali tutti in un database di prova ed esegui script di convalida su ognuno di essi, segnalando eventuali errori in modo tale da sarà garantito per essere visto e che sono facilmente e rapidamente perseguibili. E poi 150 di questi falliscono in vari punti e devono essere riparati uno alla volta.
- Quando scopri che devi impostare la replica per 1000 database.
Solo perché ho elencato più ragioni per una non significa che sia migliore.
Alcuni lettori possono ottenere valore da MSDN:Multi -Architettura dei dati del tenant . O forse Modelli di progettazione di app di tenancy SaaS . O anche Sviluppo multi-tenant Applicazioni per il Cloud, 3a edizione
