Verfügen Datenbanken mit mehreren Mandanten über mehrere Datenbanken oder gemeinsam genutzte Tabellen?

Ist eine mandantenfähige Datenbank:

• Ein DB-Server, der für jeden Kunden / Mandanten eine andere (identische) Datenbank / ein anderes Schema hat ?; oder
• Ein DB-Server mit einer Datenbank / einem Schema, auf dem Kunden / Mandanten Datensätze in denselben Tabellen gemeinsam nutzen?

Zum Beispiel könnte ich unter Option # 1 oben einen MySQL-Server an haben mydb01.example.com, und es könnte sich eine customer1Datenbank darin befinden. Diese customer1Datenbank kann beispielsweise 10 Tabellen enthalten, die meine Anwendung für diesen bestimmten Kunden (Kunde Nr. 1) unterstützen. Möglicherweise enthält es auch eine customer2Datenbank mit genau den gleichen 10 Tabellen, die jedoch nur Daten für Kunde 2 enthält. Möglicherweise gibt es eine customer3Datenbank, eine customer4Datenbank usw.

In der obigen Option 2 würde es beispielsweise nur eine einzige Datenbank / ein einziges einziges einziges Schema geben, myapp_dbin dem sich wiederum 10 Tabellen befinden (die gleichen wie oben). Aber hier sind die Daten für alle Kunden in diesen 10 Tabellen vorhanden, und sie "teilen" daher die Tabellen. Und auf der Anwendungsebene wird durch Logik und Sicherheit gesteuert, welche Kunden auf welche Datensätze in diesen 10 Tabellen zugreifen können, und es wird sorgfältig darauf geachtet, dass sich Kunde Nr. 1 niemals in der App anmeldet und die Daten von Kunde Nr. 3 usw. sieht.

Welches dieser Paradigmen stellt eine traditionelle "mandantenfähige" DB dar? Und wenn nicht, kann mir dann jemand anhand der oben beschriebenen Szenarien ein Beispiel für eine mandantenfähige Datenbank geben?

Welches dieser Paradigmen stellt eine traditionelle "mandantenfähige" DB dar?

Beide Konzepte werden als mandantenfähig bezeichnet, da es sich lediglich um ein logisches Konzept handelt, "bei dem eine einzelne Instanz von Software auf einem Server ausgeführt wird und mehrere Mandanten bedient" (aus Wikipedia ). Aber wie Sie dieses Konzept "physisch" umsetzen, liegt bei Ihnen.

Natürlich benötigt die Anwendung ein Datenbankkonzept, mit dem die Daten verschiedener Mandanten getrennt werden können, und die Idee der Mandantenfähigkeit besteht darin, einige Serverressourcen (zumindest die Hardware) gemeinsam zu nutzen, um die Ressourcennutzung zu verbessern und die Verwaltung zu vereinfachen. Eine "mandantenfähige DB" unterstützt dies also direkt , wenn Teile des Datenbankmodells oder Tabellen gemeinsam genutzt werden.

Um genau zu sein, ist es möglich, eine mandantenfähige Anwendung mit einer mandantenfreien Datenbank zu erstellen, die eine einzelne DB-Instanz pro Client bereitstellt. Dies schließt jedoch die direkte gemeinsame Nutzung von Datenbankressourcen zwischen Mandanten aus, und die Anwendungsschicht muss sicherstellen, dass der richtige Mandant mit der richtigen Datenbank verbunden ist.

Laut Microsoft hat der Begriff drei mögliche Bedeutungen (eine Datenbank für alle Mandanten oder einen Datenlaser pro Mandant).

Um Ihr Beispiel zu verwenden, wäre jeder Kunde sein eigener Mieter.

1. Eine Datenbank pro Mieter (Kunde)

   • Jeder Mieter ist von den anderen isoliert (kein versehentlicher Zugriff auf die Daten anderer Mieter)
   • Die Isolierung erleichtert auch die Verwaltung der Wiederherstellung von Daten sowie die Anpassung des Speicherbedarfs an die Bedürfnisse der Mandanten.

2. Eine gemeinsam genutzte Datenbank, separates Schema.

   • Jeder Mandant verfügt über ein eigenes Schema und seine Daten befinden sich in eigenen Tabellen.
   • Das Wiederherstellen kann zeitaufwändiger sein, da sich alle Benutzer in derselben Datenbank befinden. Sie können die Datenbank nicht einfach auf eine frühere Sicherung zurücksetzen (dies würde die Daten aller Mandanten zurücksetzen). Eine Option besteht darin, in einer neuen Datenbank wiederherzustellen und dann nur die Daten der 1 Mandanten zusammenzuführen / zu kopieren.

3. Eine gemeinsam genutzte Datenbank, ein gemeinsam genutztes Schema.

   • Die Daten aller Mieter befinden sich in denselben Tabellen. Wenn Sie beispielsweise Bestellungen verfolgen, befinden sich die Bestellungen aller Mieter in "dbo.Orders".
   • Die Daten der Mandanten werden in jeder Tabelle durch eine Spalte (möglicherweise TenantId) getrennt, die den Besitzer der Zeile anzeigt.

In diesem Artikel werden die Vor- und Nachteile erläutert: https://msdn.microsoft.com/en-us/library/aa479086.aspx

Bonus: Sie können sich das als Wohnviertel vorstellen (grob vereinfacht).

1. Jeder Mieter hat sein eigenes Haus. Sie können tun, was sie wollen, und wenn es niederbrennt, betrifft es niemanden wirklich.

2. Jeder Mieter ist im selben Gebäude, hat aber eine eigene Wohnung.

3. Jeder wohnt in der gleichen Wohnung und alle Sachen sind mit einem Haftnotiz versehen, um zu zeigen, wem sie gehören.