Sie werden sich wünschen, Sie hätten separate Datenbanken verwendet:
- Wenn Sie Clients oder Superuser jemals Berechtigungen für die Datenbanken selbst erteilen möchten.
- Wenn Sie jemals nur die Datenbank eines Clients wiederherstellen möchten, ohne die Daten der anderen zu beeinträchtigen.
- Wenn es regulatorische Bedenken hinsichtlich Ihrer Daten und Datenschutzverletzungen gibt und Sie verspätet feststellen, dass diese Vorschriften nur durch separate Datenbanken erfüllt werden können. (Aktualisierung:Etwas mehr als 4 Jahre nach dem Schreiben dieser Antwort trat die DSGVO in Kraft)
- Wenn Sie jemals Ihre Kundendaten einfach auf mehrere Datenbankserver verschieben oder anderweitig skalieren oder größere/wichtigere Kunden auf andere Hardware verschieben möchten. In einem anderen Teil der Welt.
- Wenn Sie jemals alte Kundendaten einfach archivieren und außer Betrieb nehmen möchten.
- Wenn Ihre Kunden Wert darauf legen, dass ihre Daten isoliert werden, und sie herausfinden, dass Sie etwas anderes getan haben.
- Wenn Ihre Daten vorgeladen werden und es schwierig ist, nur die Daten eines Kunden zu extrahieren, oder die Vorladung zu weit gefasst ist und Sie die gesamte Datenbank erstellen müssen, anstatt nur die Daten für einen Kunden.
- Wenn Sie vergessen, wachsam zu bleiben, und nur eine Abfrage durchschlüpft, die
AND CustomerID = @CustomerIDnicht enthält . Tipp:Verwenden Sie ein skriptbasiertes Berechtigungstool oder Schemas oder umschließen Sie alle Tabellen mit Ansichten, dieWHERE CustomerID = SomeUserReturningFunction()enthalten , oder eine Kombination davon. - Wenn Sie auf Anwendungsebene falsche Berechtigungen erhalten und Kundendaten dem falschen Kunden zugänglich gemacht werden.
- Wenn Sie verschiedene Sicherungs- und Wiederherstellungsschutzstufen für verschiedene Clients haben möchten.
- Sobald Sie erkennen, dass der Aufbau einer Infrastruktur zum Erstellen, Bereitstellen, Konfigurieren, Bereitstellen und anderweitigen Hoch- und Herunterfahren neuer Datenbanken die Investition wert ist, weil Sie dadurch gezwungen sind, gut darin zu werden.
- Wenn Sie die Möglichkeit nicht berücksichtigt haben, dass eine Gruppe von Personen Zugriff auf die Daten mehrerer Kunden benötigt, und Sie eine Abstraktionsebene über
Customerbenötigen weilWHERE CustomerID = @CustomerIDwird es jetzt nicht schneiden. - Wenn Hacker auf Ihre Websites oder Systeme abzielen und Sie es ihnen leicht gemacht haben, alle Daten all Ihrer Kunden auf einen Schlag zu erhalten, nachdem Sie die Administratoranmeldeinformationen in nur einem erhalten haben Datenbank.
- Wenn die Ausführung Ihrer Datenbanksicherung 5 Stunden dauert und dann fehlschlägt.
- Wenn Sie die Enterprise Edition Ihres DBMS benötigen, können Sie komprimierte Backups erstellen, sodass das Kopieren der Backup-Datei über das Netzwerk weniger als 5 Stunden mehr dauert .
- Wenn Sie jeden Tag die gesamte Datenbank auf einem Testserver wiederherstellen müssen, was 5 Stunden dauert, und Validierungsskripts ausführen, die 2 Stunden dauern.
- Wenn nur wenige Ihrer Kunden eine Replikation benötigen und Sie sie auf alle Ihre Kunden anwenden müssen, anstatt nur auf diese wenigen.
- Wenn Sie einen Regierungskunden übernehmen möchten und feststellen, dass Sie einen separaten Server und eine separate Datenbank verwenden müssen, Ihr Ökosystem jedoch um einen einzigen Server und eine einzelne Datenbank herum aufgebaut wurde und die Änderung einfach zu schwierig ist oder zu lange dauert .
Sie werden froh sein, dass Sie separate Datenbanken verwendet haben:
- Wenn ein Pilot-Rollout bei einem Kunden völlig explodiert und die anderen 999 Kunden völlig unberührt bleiben. Und Sie können aus dem Backup wiederherstellen, um das Problem zu beheben.
- Wenn eine Ihrer Datenbanksicherungen fehlschlägt und Sie nur diese in 25 Minuten reparieren können, anstatt den gesamten 10-stündigen Prozess erneut zu starten.
Sie werden sich wünschen, Sie hätten eine einzige Datenbank verwendet:
- Wenn Sie einen Fehler entdecken, der alle 1000 Clients betrifft, und die Bereitstellung des Fixes für 1000 Datenbanken schwierig ist.
- Wenn Sie Berechtigungen auf Datenbankebene falsch erhalten und Kundendaten dem falschen Kunden zugänglich gemacht werden.
- Wenn Sie die Möglichkeit nicht berücksichtigt haben, dass eine Gruppe von Personen Zugriff auf eine Teilmenge aller Datenbanken benötigt (vielleicht zwei Kunden fusionieren).
- Als Sie nicht daran gedacht haben, wie schwierig es wäre, zwei verschiedene Datendatenbanken zusammenzuführen.
- Wenn Sie zwei verschiedene Datendatenbanken zusammengeführt haben und feststellen, dass eine die falsche war, und Sie keine Wiederherstellung nach diesem Szenario geplant haben.
- Wenn Sie versuchen, über 32.767 Kunden/Datenbanken auf einem einzelnen Server hinauszuwachsen und feststellen, dass dies das Maximum in SQL Server 2012 ist.
- Wenn Sie feststellen, dass die Verwaltung von mehr als 1.000 Datenbanken ein größerer Albtraum ist, als Sie sich jemals vorgestellt haben.
- Wenn Sie feststellen, dass Sie einen neuen Kunden nicht einfach durch Hinzufügen einiger Daten in eine Tabelle einbinden können und Sie eine Reihe von beängstigenden und komplizierten Skripts ausführen müssen, um eine neue Datenbank zu erstellen, zu füllen und Berechtigungen festzulegen.
- Wenn Sie jeden Tag 1000 Datenbanksicherungen ausführen müssen, stellen Sie sicher, dass alle erfolgreich sind, kopieren Sie sie über das Netzwerk, stellen Sie sie alle in einer Testdatenbank wieder her und führen Sie Validierungsskripts für jede einzelne aus, um alle Fehler auf eine Weise zu melden die garantiert gesehen werden und die einfach und schnell umsetzbar sind. Und dann fallen 150 davon an verschiedenen Stellen aus und müssen einzeln repariert werden.
- Wenn Sie herausfinden, dass Sie die Replikation für 1000 Datenbanken einrichten müssen.
Nur weil ich mehr Gründe für einen aufgelistet habe, heißt das nicht, dass er besser ist.
Einige Leser können von MSDN:Multi profitieren -Tenant-Datenarchitektur . Oder vielleicht SaaS Tenancy App Design Patterns . Oder sogar Multi-Tenant entwickeln Anwendungen für die Cloud, 3. Auflage
