Meerdere databases versus één database met logisch gepartitioneerde gegevens

Je zou willen dat je aparte databases had gebruikt:

• Als je ooit toestemming wilt geven aan de databases zelf aan clients of superusers.
• Als u ooit de database van één klant wilt herstellen zonder de gegevens van de andere te beïnvloeden.
• Als er regelgevende problemen zijn met betrekking tot uw gegevens en gegevensinbreuken, en u ontdekt te laat dat aan deze voorschriften alleen kan worden voldaan door afzonderlijke databases te hebben. (Update:iets meer dan 4 jaar na het schrijven van dit antwoord, werd de AVG van kracht)
• Als u ooit uw klantgegevens gemakkelijk naar meerdere databaseservers wilt verplaatsen of anderszins wilt uitschalen, of grotere/belangrijkere klanten wilt verplaatsen naar andere hardware. In een ander deel van de wereld.
• Als u ooit gemakkelijk oude klantgegevens wilt archiveren en buiten gebruik stellen.
• Als uw klanten het belangrijk vinden dat hun gegevens in silo's worden opgeslagen, en ze ontdekken dat u het anders deed.
• Als uw gegevens zijn gedagvaard en het is moeilijk om de gegevens van slechts één klant te extraheren, of de dagvaarding is te breed en u moet de hele database produceren in plaats van alleen de gegevens voor die ene klant.
• Als je vergeet waakzaam te blijven en er komt maar één vraag voorbij die AND CustomerID = @CustomerID niet bevatte . Hint:gebruik een gescripte machtigingstool of schema's, of wikkel alle tabellen in met views die WHERE CustomerID = SomeUserReturningFunction() bevatten , of een combinatie hiervan.
• Als u verkeerde machtigingen krijgt op applicatieniveau en klantgegevens worden blootgesteld aan de verkeerde klant.
• Als u verschillende niveaus van back-up- en herstelbescherming wilt hebben voor verschillende clients.
• Zodra je je realiseert dat het bouwen van een infrastructuur om nieuwe databases te maken, te leveren, te configureren, te implementeren en anderszins op te zetten, de investering waard is, omdat het je dwingt om er goed in te worden.
• Toen je de mogelijkheid niet toestond dat een bepaalde groep mensen toegang nodig heeft tot de gegevens van meerdere klanten, en je een abstractielaag nodig hebt bovenop Customer omdat WHERE CustomerID = @CustomerID zal het nu niet redden.
• Als hackers zich op uw sites of systemen richten en u het ze gemakkelijk heeft gemaakt om alle gegevens van al uw klanten in één klap te krijgen nadat ze in slechts één beheerdersreferenties hebben gekregen database.
• Als het uitvoeren van uw databaseback-up 5 uur duurt en vervolgens mislukt.
• Als u de Enterprise-editie van uw DBMS nodig heeft, zodat u gecomprimeerde back-ups kunt maken, zodat het kopiëren van het back-upbestand via het netwerk minder dan 5 uur duurt meer .
• Als je elke dag de hele database moet herstellen naar een testserver, wat 5 uur duurt, en validatiescripts moet uitvoeren die 2 uur in beslag nemen.
• Als slechts een paar van uw klanten replicatie nodig hebben en u deze op al uw klanten moet toepassen in plaats van slechts op die paar.
• Als u een overheidsklant wilt aannemen en ontdekt dat u een aparte server en database moet gebruiken, maar uw ecosysteem is gebouwd rond een enkele server en database en het is gewoon te moeilijk of duurt te lang om te veranderen .

Je zult blij zijn dat je aparte databases hebt gebruikt:

• Wanneer een pilot-implementatie naar één klant volledig explodeert en de andere 999 klanten volledig onaangetast blijven. En u kunt herstellen vanaf een back-up om het probleem op te lossen.
• Als een van je databaseback-ups mislukt en je die ene in 25 minuten kunt repareren in plaats van het hele proces van 10 uur opnieuw te beginnen.

Je zou willen dat je een enkele database had gebruikt:

• Als je een bug ontdekt die alle 1000 clients treft en het moeilijk is om de fix in 1000 databases te implementeren.
• Als u verkeerde machtigingen krijgt op databaseniveau en klantgegevens worden blootgesteld aan de verkeerde klant.
• Toen je de mogelijkheid niet toestond dat een bepaalde groep mensen toegang nodig had tot een subset van alle databases (misschien fuseren twee klanten).
• Toen je niet had gedacht hoe moeilijk het zou zijn om twee verschillende databanken samen te voegen.
• Als je twee verschillende databases met gegevens hebt samengevoegd en je realiseert je dat de ene de verkeerde was, en je was niet van plan om uit dit scenario te herstellen.
• Als je probeert voorbij 32.767 klanten/databases op één server te groeien en je ontdekt dat dit het maximum is in SQL Server 2012.
• Als je je realiseert dat het beheren van meer dan 1000 databases een grotere nachtmerrie is dan je ooit had gedacht.
• Als je je realiseert dat je een nieuwe klant niet kunt binnenhalen door alleen wat gegevens in een tabel toe te voegen, en je een heleboel enge en gecompliceerde scripts moet uitvoeren om een ​​nieuwe database te maken, te vullen en machtigingen in te stellen.
• /li>
• Als je elke dag 1000 databaseback-ups moet uitvoeren, zorg er dan voor dat ze allemaal slagen, kopieer ze over het netwerk, herstel ze allemaal naar een testdatabase en voer op elke database validatiescripts uit, waarbij je eventuele fouten op een zodanige manier rapporteert dat zullen gegarandeerd worden gezien en die gemakkelijk en snel kunnen worden uitgevoerd. En dan falen er 150 op verschillende plaatsen en moeten ze één voor één worden gerepareerd.
• Als je erachter komt dat je replicatie voor 1000 databases moet instellen.

Alleen omdat ik meer redenen voor één heb genoemd, wil nog niet zeggen dat het beter is.

Sommige lezers kunnen baat hebben bij MSDN:Multi -Tenantgegevensarchitectuur . Of misschien SaaS Tenancy App Design Patterns . Of zelfs Multi-tenant ontwikkelen Applicaties voor de cloud, 3e editie