Flera databaser kontra enstaka databas med logiskt partitionerade data

Du skulle önska att du hade använt separata databaser:

• Om du någonsin vill ge tillstånd till databaserna själva till klienter eller superanvändare.
• Om du någonsin vill återställa bara en klients databas utan att påverka de andras data.
• Om det finns regulatoriska problem som styr dina data och dataintrång, och du för sent upptäcker att dessa regler bara kan uppfyllas genom att ha separata databaser. (Uppdatering:lite över fyra år efter att detta svar skrevs trädde GDPR i kraft)
• Om du någon gång enkelt vill flytta dina kunddata till flera databasservrar eller på annat sätt skala ut, eller flytta större/viktigare kunder till annan hårdvara. I en annan del av världen.
• Om du någonsin vill enkelt arkivera och avveckla gamla kunddata.
• Om dina kunder bryr sig om att deras data kommer i silo och de får reda på att du gjorde något annat.
• Om din data är stämd och det är svårt att extrahera bara en kunds data, eller om stämningen är för bred och du måste producera hela databasen istället för bara data för en klient.
• När du glömmer att vara vaksam och bara en fråga glider igenom som inte inkluderade AND CustomerID = @CustomerID . Tips:använd ett skriptbehörighetsverktyg, eller scheman, eller omslut alla tabeller med vyer som inkluderar WHERE CustomerID = SomeUserReturningFunction() , eller någon kombination av dessa.
• När du får felaktiga behörigheter på applikationsnivå och kunddata exponeras för fel kund.
• När du vill ha olika nivåer av säkerhetskopierings- och återställningsskydd för olika klienter.
• När du inser att det är värt investeringen att bygga en infrastruktur för att skapa, tillhandahålla, konfigurera, distribuera och på annat sätt snurra upp/ned nya databaser eftersom det tvingar dig att bli bra på det.
• När du inte tillät möjligheten för någon klass av människor att behöva tillgång till flera kunders data, och du behöver ett lager av abstraktion ovanpå Customer eftersom WHERE CustomerID = @CustomerID kommer inte att klippa det nu.
• När hackare riktar in sig på dina webbplatser eller system och du gjorde det enkelt för dem att få all data från alla dina kunder i ett svep efter att ha fått administratörsuppgifter på bara ett databas.
• När din databassäkerhetskopiering tar 5 timmar att köra och sedan misslyckas.
• När du måste skaffa Enterprise-utgåvan av ditt DBMS så att du kan göra komprimerade säkerhetskopior så att kopieringen av säkerhetskopian över nätverket tar mindre än 5 timmar mer .
• När du måste återställa hela databasen varje dag till en testserver som tar 5 timmar och köra valideringsskript som tar 2 timmar att slutföra.
• När bara ett fåtal av dina kunder behöver replikering och du måste tillämpa det på alla dina kunder istället för bara de få.
• När du vill anställa en statlig kund och upptäcka att de kräver att du använder en separat server och databas, men ditt ekosystem byggdes kring en enda server och databas och det är helt enkelt för svårt eller kommer att ta för lång tid att ändra .

Du kommer att vara glad att du använde separata databaser:

• När en pilotutrullning till en kund exploderar helt och de andra 999 kunderna är helt opåverkade. Och du kan återställa från säkerhetskopia för att åtgärda problemet.
• När en av dina databassäkerhetskopior misslyckas och du kan fixa just den på 25 minuter istället för att starta om hela 10-timmarsprocessen.

Du önskar att du hade använt en enda databas:

• När du upptäcker en bugg som påverkar alla 1000 klienter och distribuera korrigeringen till 1000 databaser är svårt.
• När du får felaktiga behörigheter på databasnivå och kunddata exponeras för fel kund.
• När du inte tillät möjligheten för någon klass av människor att behöva tillgång till en delmängd av alla databaser (kanske två kunder slås samman).
• När du inte tänkte på hur svårt det skulle vara att slå samman två olika databaser med data.
• När du har slagit samman två olika databaser med data och inser att en var fel, och du inte planerade att återhämta dig från det här scenariot.
• När du försöker växa förbi 32 767 kunder/databaser på en enda server och upptäcker att detta är maxvärdet i SQL Server 2012.
• När du inser att hantering av 1 000+ databaser är en större mardröm än du någonsin föreställt dig.
• När du inser att du inte kan ta med en ny kund bara genom att lägga till data i en tabell, och du måste köra en massa läskiga och komplicerade skript för att skapa, fylla i och ange behörigheter för en ny databas.
• När du måste köra 1 000 säkerhetskopieringar av databaser varje dag, se till att de alla lyckas, kopiera dem över nätverket, återställ dem alla till en testdatabas och kör valideringsskript på var och en och rapportera eventuella fel på ett sätt som kommer garanterat att synas, och som är lätta och snabbt genomförbara. Och sedan misslyckas 150 av dessa på olika ställen och måste åtgärdas en i taget.
• När du får reda på det måste du ställa in replikering för 1000 databaser.

Bara för att jag har listat fler skäl till en betyder det inte att det är bättre.

Vissa läsare kan få värde från MSDN:Multi -Tenant Data Architecture . Eller kanske SaaS Tenancy App Design Patterns . Eller till och med Utveckla Multi-tenant Applikationer för molnet, 3:e upplagan