Flere databaser vs enkelt database med logisk opdelte data

Du ville ønske, at du havde brugt separate databaser:

• Hvis du nogensinde ønsker at give tilladelser til selve databaserne til klienter eller superbrugere.
• Hvis du nogensinde ønsker at gendanne kun én klients database uden at påvirke de andres data.
• Hvis der er lovgivningsmæssige bekymringer, der styrer dine data og databrud, og du for sent opdager, at disse regler kun kan opfyldes ved at have separate databaser. (Opdatering:lidt over 4 år efter skrivningen af ​​dette svar trådte GDPR i kraft)
• Hvis du nogensinde vil nemt flytte dine kundedata til flere databaseservere eller på anden måde skalere ud, eller flytte større/vigtigere kunder til anden hardware. I en anden del af verden.
• Hvis du nogensinde vil nemt arkivere og afvikle gamle kundedata.
• Hvis dine kunder bekymrer sig om, at deres data bliver siloiseret, og de finder ud af, at du gjorde noget andet.
• Hvis dine data er stævnet, og det er svært at udtrække kun én kundes data, eller stævningen er for bred, og du skal producere hele databasen i stedet for kun dataene for den ene klient.
• Når du glemmer at være årvågen og kun én forespørgsel glider igennem, som ikke indeholdt AND CustomerID = @CustomerID . Tip:brug et script-tilladelsesværktøj eller skemaer, eller omslut alle tabeller med visninger, der inkluderer WHERE CustomerID = SomeUserReturningFunction() , eller en kombination af disse.
• Når du får forkerte tilladelser på applikationsniveau, og kundedata eksponeres for den forkerte kunde.
• Når du vil have forskellige niveauer af sikkerhedskopiering og gendannelsesbeskyttelse for forskellige klienter.
• Når du først indser, at opbygning af en infrastruktur til at skabe, klargøre, konfigurere, implementere og på anden måde spinne nye databaser op/ned, er investeringen værd, fordi det tvinger dig til at blive god til det.
• Når du ikke tillod muligheden for, at en gruppe mennesker skulle have adgang til flere kunders data, og du har brug for et lag af abstraktion oven på Customer fordi WHERE CustomerID = @CustomerID vil ikke klippe det nu.
• Når hackere målretter mod dine websteder eller systemer, og du gjorde det nemt for dem at få alle data fra alle dine kunder i ét hug efter at have fået administratoroplysninger på kun én database.
• Når din databasesikkerhedskopiering tager 5 timer at køre og derefter mislykkes.
• Når du skal have Enterprise-udgaven af ​​dit DBMS, så du kan lave komprimerede sikkerhedskopier, så kopiering af backupfilen over netværket tager mindre end 5 timer mere .
• Når du skal gendanne hele databasen hver dag til en testserver, som tager 5 timer, og køre valideringsscripts, der tager 2 timer at fuldføre.
• Når kun få af dine kunder har brug for replikering, og du skal anvende det på alle dine kunder i stedet for kun de få.
• Når du vil ansætte en offentlig kunde og finde ud af, at de kræver, at du bruger en separat server og database, men dit økosystem er bygget op omkring en enkelt server og database, og det er bare for svært eller vil tage for lang tid at ændre .

Du vil være glad for, at du brugte separate databaser:

• Når en pilotudrulning til én kunde eksploderer fuldstændigt, og de andre 999 kunder er fuldstændig upåvirkede. Og du kan gendanne fra backup for at løse problemet.
• Når en af ​​dine databasesikkerhedskopier fejler, og du kan rette netop den på 25 minutter i stedet for at starte hele 10-timers processen forfra.

Du ville ønske, at du havde brugt en enkelt database:

• Når du opdager en fejl, der påvirker alle 1000 klienter, og det er svært at implementere rettelsen til 1000 databaser.
• Når du får forkerte tilladelser på databaseniveau, og kundedata eksponeres for den forkerte kunde.
• Når du ikke tillod muligheden for, at en gruppe mennesker skulle have adgang til en delmængde af alle databaserne (måske to kunder smelter sammen).
• Når du ikke tænkte på, hvor svært det ville være at flette to forskellige databaser med data.
• Når du har slået to forskellige databaser med data sammen og indser, at den ene var den forkerte, og du ikke planlagde at komme dig efter dette scenarie.
• Når du forsøger at vokse forbi 32.767 kunder/databaser på en enkelt server og finder ud af, at dette er maksimum i SQL Server 2012.
• Når du indser, at administration af mere end 1.000 databaser er et større mareridt, end du nogensinde havde forestillet dig.
• Når du indser, at du ikke kan ombord på en ny kunde blot ved at tilføje nogle data i en tabel, og du skal køre en masse skræmmende og komplicerede scripts for at oprette, udfylde og angive tilladelser på en ny database.
• Når du skal køre 1000 databasesikkerhedskopier hver dag, skal du sørge for, at de alle lykkes, kopiere dem over netværket, gendanne dem alle til en testdatabase og køre valideringsscripts på hver enkelt, og rapportere eventuelle fejl på en måde, som vil med garanti blive set, og som nemt og hurtigt kan handles. Og så fejler 150 af disse forskellige steder og skal rettes én ad gangen.
• Når du finder ud af det, skal du konfigurere replikering for 1000 databaser.

Bare fordi jeg har nævnt flere grunde til en, betyder det ikke, at den er bedre.

Nogle læsere kan få værdi fra MSDN:Multi -Lejer dataarkitektur . Eller måske SaaS Tenancy App Design Patterns . Eller endda Udvikling af multilejer Programmer til skyen, 3. udgave