Mandantenfähigkeit - Einzelne Datenbank gegen mehrere Datenbanken

20

Wir haben eine Reihe von Kunden, deren Systeme einige Funktionen gemeinsam haben, aber auch ein gewisses Maß an Vielfalt aufweisen. Die Zahl der Kunden wächst - immer eine gesunde Sache! - und auch die Vielfalt zwischen ihren Unternehmen nimmt zu.

Derzeit gibt es eine einzige ASP.Net-Website (Web Forms) (im Gegensatz zu einem Webprojekt), die Unterordner für jeden Mandanten enthält und die nicht standardmäßigen Seiten dieses Mandanten enthält. Es gibt ein separates Modellprojekt, das sich mit dem Datenbankzugriff und der Geschäftslogik befasst.

Was ist vorzuziehen - und am wichtigsten, warum - zwischen (a) 1 Datenbank pro Client mit nur den Funktionen, die mit diesem Client verbunden sind; oder (b) eine einzelne Datenbank, die von allen Clients gemeinsam genutzt wird, wobei nur eine Teilmenge von Tabellen von einem Client verwendet wird.

Die Hauptanliegen innerhalb des Geschäfts sind erledigt:

Wartung mehrerer Assets - Backups, Versionskontrolle und dergleichen
Förderung der Wiederverwendung so weit wie möglich

Wie würden Sie sicherstellen, dass diese Bedenken ausgeräumt werden, welche Lösung ist vorzuziehen und warum? (Ich habe auch Antworten auf ähnliche Fragen zusammengestellt.)

database-design projects-and-solutions multitenancy

— RichardW1001
quelle

Besteht eine Chance, dass dies in eine PaaS-Cloud-Umgebung wie Azure verschoben wird? In diesem Fall sollten Sie auch Best Practices für die Umwelt berücksichtigen. Als ich das letzte Mal nachgesehen habe, hat MS mehrere Datenbanken für mandantenfähige Software auf Azure empfohlen.

— Harper Shelby

Danke für die Frage. Ich habe mich über ähnliche Dinge gewundert, aber ich habe es nicht geschafft, das Format so eloquent in Frage zu stellen wie Sie.

— MathAttack

Sie sollten die mandantenfähige Blogserie von Ayende lesen. Er macht einige sehr gute Punkte über Multi vs Single-Datenbank.

— Sebazzz,

12

Hier sind die Highlights aus Untersuchungen aus anderen Quellen (ursprünglich aus Revision 2 der Frage ):

Soll ich eine Datenbank pro Anwendung verwenden oder eine einzelne Datenbank für mehrere Anwendungen freigeben?
Unterstützung für Mandantenfähigkeit
Mandantenfähige MSDN -Datenarchitektur
SO Wie erstelle ich eine mandantenfähige Datenbank mit gemeinsam genutzten Tabellenstrukturen?
CloudExpo SaaS - Entwurfsoptionen für mandantenfähige Datenbanken
MSDN-Blogs Der Umstieg auf ein mandantenfähiges Datenbankmodell ist mit SQL Azure-Verbänden ganz einfach
Fragen Sie SQL Server Central Eine Datenbank oder mehrere?
SQL Server Central Mischen von Tabellen aus verschiedenen Datenbanken / Anwendungen in eine Datenbank
Ayende @ Rahien blog Mandantenfähigkeit - Das physikalische Datenmodell
Datenbankarchitektur mit mehreren Mandanten für Code-Projekte
Joel über Software -Datenbankdesign mit mehreren Mandanten
SO Mehrfachanwendung mit einer Datenbank?
SO Einzelne oder mehrere Datenbanken
Code Rant - Mandantenfähigkeit Teil 1, Strategie und Teil 2, Komponenten und Kontext

— user40980
quelle

10

Wenn Sie SQL Server verwenden, verwenden Sie eine Datenbank, aber Schemas. Verwenden Sie dbo für Dinge, die für alle Clients allgemein sind, und erstellen Sie ein Schema für jeden Client, und legen Sie dieses als Standardschema für Benutzer dieses Clients fest. Jetzt können Sie ein allgemeines Objekt (z. B. einen getBudget-Prozess) im dbo-Schema und ein benutzerdefiniertes Objekt für den Client in seinem Schema mit demselben Namen haben.

— HLGEM
quelle

+1 Damit können Sie auch vermeiden, MSDTC konfigurieren und den damit verbundenen Overhead (Zwei-Phasen-Commits) übernehmen zu müssen

— brian

Und hoffentlich vermeiden Sie die Falle, Spalten wie CustomField1 bis CustomField30 und / oder Tabellen wie Budget, BudgetEx, BudgetCustom, BudgetCustomerName, BudgetAnotherCustomerName usw. zu haben

— jfrankcarr

Es gibt eine vorhandene Datenzugriffsebene, die viele gespeicherte Prozeduren verwendet - 190 Tabellen, 5 codegenerierte Prozeduren pro Tabelle sowie einige benutzerdefinierte -, während das mittelfristige Ziel die Einführung von Entity Framework ist. Wäre es erforderlich, die gespeicherten Prozeduren zu replizieren Prozeduren für jedes Schema?

— RichardW1001

@ RichardW1001: kommt darauf an. Sie können dynamisches SQL in der SP ausführen, um es generisch zu machen, aber das hängt natürlich davon ab, dass sie zumindest eine etwas ähnliche Struktur haben. Eine mögliche Alternative für dynamisches SQL wären Synonyme , die meines Wissens leider systemweit und nicht in einer Transaktion enthalten sind und sich daher nicht für die gleichzeitige Verwendung mit unterschiedlichen Werten eignen.

— Jmoreno

Wenn wir mehrere Schemas verwenden, können mit EF Code First alle Schemas nach dem Start des Systems auf die neueste Version migriert werden?

— Yashvit

4

Da die Datenbanken und Funktionen der Clients unterschiedlich sind, bedeutet dies, dass sie zu einem bestimmten Zeitpunkt unterschiedliche Systeme darstellen. In diesem Fall würde ich separate Systeme empfehlen, da die Kosten für die Pflege der Anpassungen für jeden Client die Vorteile eines einzelnen Systems überwiegen Datenbanksystem.

Einzelne Datenbanksysteme eignen sich am besten, wenn die Änderungen zwischen verschiedenen Kunden lediglich Konfigurationen sind, jedoch keine zusätzlichen Funktionen für jeden Client.

— Stephen Senkomago Musoke
quelle

Was würden Sie vorschlagen, um die allgemeine Funktionalität mit minimalen Schmerzen zu verwalten?

— RichardW1001

1

Pflegen Sie in Ihrem Versionskontrollsystem einen Kopf für die Kernanwendung und erstellen Sie für jeden Kunden eine Hauptniederlassung mit Unterzweigen für neue Funktionen, die sie pflegen müssen. Entwickeln Sie kundenspezifische Funktionen in den Filialen, mit Optionen zum Aktualisieren des Trunks usw. Sie können kundenspezifische Umgebungen dann problemlos bei Bedarf

— auslagern

3

Sie vermissen einige Bedenken. Probleme werden mit dem Wachstum kommen. Wenn Sie davon ausgehen können, dass Sie eines Tages größer werden als ein DB-Server, bereitet Ihnen eine komplexe Datenbank definitiv Kopfzerbrechen. Es sei denn, Sie investieren im Voraus in Architektur. Aber es ist auch teuer Schritt)

Vergessen Sie also nicht, dass es um ein Vielfaches billiger und einfacher ist, nur wenige Datenbanken zu skalieren als riesige.

— stimulieren
quelle

Haben Sie Daten, die die einfache Skalierung bestätigen? Wenn ja, wäre dies ein sehr überzeugender Fall. Könnten Sie die anderen fehlenden Bedenken näher erläutern? Ich versuche, auf beiden Seiten ein möglichst vollständiges Argument zu bilden.

— RichardW1001

1

Ein Bereich, den ich in den Antworten nicht gesehen habe, sind die Probleme beim korrekten Sichern einer mandantenfähigen DB-Anwendung. Multi-Tenant-Apps müssen sehr sorgfältig entwickelt werden, um Sicherheitsprobleme zu vermeiden. Die meisten Datenbanken und Apps bieten eine gewisse, aber keine vollständige Isolation. In der Regel gibt es Möglichkeiten, Daten direkt oder indirekt über die DB-Schemata abzuleiten. Und eine ganze Reihe von freigegebenen Ressourcen (Protokolle und andere Dateien, DBA-Tabellen, Cursor ...), die zumindest zu leichten Denial-of-Service-Angriffen auf andere Mandanten und in der Regel zu vielem mehr führen können.

— Reiher
quelle