Ein Schema für alle oder Trennung von Schema für jeden Kunden?

Question

Nehmen wir an, Sie erstellen eine Anwendung, die mehrere Kunden bedienen muss (Daten werden nie zwischen Kunden geteilt) und die Kundendaten selbst sind sensibel.

Wie würden Sie die Datenbank entwerfen, um zu verhindern, dass Daten eines Kunden plötzlich (z. B. ein Fehler) für einen anderen sichtbar sind?

z. Wir haben eine Projekttabelle, die Projekte eines Kunden enthält. Jetzt könnten wir alle Projekte (von allen Kunden) in diese Tabelle übernehmen oder ein Schema für jeden Kunden erstellen.

Ich mag die Idee der Schematrennung (weil es die Daten völlig trennen würde), aber wie ich es nie getan habe, bin ich nicht sicher, ob dies ein guter Ansatz ist (zB Änderung des Schemas würde die Wartung aller Kundenschemata erfordern)).

Wichtig: Die Anwendung enthält Stammdaten, die für alle Kunden freigegeben sind (z. B. Kundenkonten, Einstellungen, Vorlagen usw.). Also ein weiterer Nachteil, was ich erwarte, wäre die Wartung von mehreren Verbindungen zur gleichen Zeit ...

UPDATE: Wäre es möglich, nur das Schema automatisch zu replizieren?

Answer 1

Um die Option richtig zu gewichten, denke ich, dass Sie die Qualität Ihres Anwendungscodes analysieren müssen. Ich habe viele Systeme für große Kunden entwickelt, die Datenbanken gemeinsam nutzen, wo wir uns nie Gedanken über Cross-Sharing-Daten gemacht haben. Wenn Sie qualitativ hochwertigen Code haben, bei dem die Berechtigungslogik sicher ist, würde ich immer ein Schema verwenden; Wartung ist so viel einfacher, so

Auf der anderen Seite. Wenn Sie asp-Seiten ohne Business-Objekt-Bibliothek ohne standardmäßige und zentralisierte Autorisierungslogik zusammengeschustert haben; dann verwenden Sie sicher verschiedene Datenbanken mit eindeutigen Logins pro Kunde.

Answer 2

Ich denke, dass Ihre Idee, jeden Kunden zu trennen, die beste Option wäre. Ihre Stammdaten könnten für sich behalten werden und wären in Ordnung, solange Clients nicht auf diese Tabelle zugreifen (oder zumindest häufig darauf zugreifen). Der Schlüssel wäre bei der Trennung aller sensiblen Daten des Kunden, dass dies zu mehr Arbeit führen würde. Aber hey, das ist es, was Sie für die Erweiterung Ihres Geschäfts bekommen.

Answer 3

Mit Ihren Anforderungen, separate Kunden DB-Schema klingt wie eine gute Idee. Es wird ein bisschen Kopfschmerzen, aber nicht so viel wie eine Klage.

Answer 4

Sie könnten stattdessen eine einzelne Master-Tabelle erstellen und pro Kunde eine Ansicht haben. Alle Abfragen würden dann durch diese Ansicht gehen, die alles außerhalb des relevanten Kunden herausfiltern würde.

Dies erleichtert die Wartung, da die Ansichten nur eine einzige Einschränkung (für den Kunden) definieren und keine weiteren Schemainformationen enthalten.

Hier ist ein Beispiel in MySQL (nicht die beste DB für Ansichten, aber hey)

CREATE VIEW projects.foocust AS SELECT * FROM projects WHERE customer = 'foocust'; 

Answer 5

Mein Rat der Daten für jeden Kunden so weit wie möglich zu trennen wäre. Mit SQL Server würde ich die Daten jedes Kunden in einer separaten Datenbank speichern (in einer Instanz von SQL Server können mehrere separate Datenbanken vorhanden sein). Wenn Sie diese Option nicht haben, könnte ein Schema etwas sehr ähnliches tun.