Mandantenfähigkeit und Zentrale Tabellen

Guten Morgen,

es geht hier um Mandantenfähigkeit und Zentralen Tabellen mit SQL-Server und Entity Framework.

Mandantenfähigkeit laut Definition ist das speichern der Daten in getrennt voneinader liegenden Datenbeständen pro Mandant (Firma, Filiale, Kunde - was auch immer man als Mandant definiert).
Ich definiere jetzt hier einen Mandanten als Filiale einer Firma.
Im Idealfall würde man nun also pro mandant eine Datenbank anlegen in der alle zu dieser Filiale gehörigen Daten gespeichert werden.

Erste frage hier also:
Im MSSQL Server habe ich hier für 2 Möglichkeiten.
Zum einen kann ich wirklich eigene Datenbanken anlegen die alle das Standard-Schema [dbo] besitzen. Zum anderen kann ich aber auch alle Tabellen mehrfach anlegen, aber in unterschiedliche Schemas legen (intuitiv wäre der Schema-Name dann der Name des Mandanten).
Weiß hier zufällig jmd. wie man dies in der Praxis umsetzt (also mehrere Datenbanken oder Mehrere Schemas) ?
Kann jmd dazu evtl. kurz Vor- oder Nachteile beider Herangehensweisen erklären?

Jetzt noch die zweite Frage:
Wenn man nun Zentrale Daten für diese Mandanten hat (ein Realistischer Fall wäre z.b. das alle Mandanten auf die selben Adressen zugreifen) dann würde die Tabelle mit den Adressen "zentral sein".
Wie realisiert man diese zentrale Adresstabelle jetzt?
Würde man eine extra Datenbank "Zentral" anlegen in der alle zentralen Tabellen, wie z.b. die Adress-Tabelle liegt? Oder würde man in jedem Mandanten eine Adress-Tabelle haben und die Daten durch den SQL-Server in die Adress-Tabellen der weiteren Datenbanken kopieren lassen?
Letzteres wäre bei einer Sicherung der einzelnen Datenbank vermutlich praktischer.

Mandantenfähigkeit kann man auch anders umsetzen. Eine technisch sehr einfache Variante, die z. B. die SAP in ihrem ERP-System nutzt, ist die Speicherung aller Datensätze mit einer Mandantennummer. Mandantenunabhängige Tabellen haben das Feld nicht, alle anderen Tabellen schon. Zugriffe auf mandantenabhängige Tabellen dürfen dann natürlich nur inklusive der Mandantennummer erfolgen. Damit das auch eingehalten wird, sollte man alle Zugriffe auf die Datenbank dann über ein Repository ausführen, das die Zugriffe entsprechend vornimmt.

Das ginge auch, ist aber Support-Aufwändiger und aufwändiger einen einzelnen Mandanten zu sichern.
Aber Interessant das SAP sowas macht 😃

Hi,

der Normalfall ist sicherlich den Mandanten als Feld mit in allen Tabellen aufzunehmen und bei den SQLs zu verwenden. Zentrale Tabellen zu Duplizieren führt dazu, dass diese auseinanderlaufen und Chaos entsteht.

Wenn Du überhaupt mit unterschiedlichen Schemata pro Mandant arbeiten möchtest (was ich nicht empfehle) solltest Du die zentralen Tabellen über Synonnyme (bzw. Aliase) oder schlimmstenfalls Views einblenden, um diese nur einmal vorzuhalten. Das spircht m.E. gegen unterschiedliche DBen, da man beim Zugriff über DB-Grenzen gerne mal "Überraschungen" erlebt.

Gruß
f_igy

Hallo GarlandGreene,

wobei bei SAP die Spalte Mandant schon einige Besonderheiten hat. Wenn man sie in der where-Bedingung der SQL-Abfrage nicht angibt, werden - wenn ich mich richtig erinnere - trotzdem nur die Sätze des aktuellen Mandanten gelesen bzw. beeinflusst. Auch gibt es Zugriffsrechte, so das man nur die Sätze lesen/schreiben kann, für die man berechtigt ist, selbst wenn man versuchen würde, im SQL-Statement einen anderen Mandanten zu selektieren.

Das alles hätte man mit einer einfachen Spalte in einer normalen Tabelle nicht (ohne weiteres). Trotzdem würde das für eine einfach Mandantenfähigkeit reichen, nicht aber wenn aber die Anforderungen an die Trennung höher sind.

herbivore

Es kommt auf viele Details an. Ich glaube z.B. mit Azure würde ich die Variante mit mehreren Datenbanken bevorzugen, weil das sehr gut skalieren sollte. Außerdem kannst du mit EF Code First und Mitgration viel Chaos vermeiden.

wobei bei SAP die Spalte Mandant schon einige Besonderheiten hat. Wenn man sie in der where-Bedingung der SQL-Abfrage nicht angibt, werden - wenn ich mich richtig erinnere - trotzdem nur die Sätze des aktuellen Mandanten gelesen bzw. beeinflusst.

Das kann ich bestätigen.

Mandantenübergreifende Selects sind nur mit dem Zusatz Client Specified möglich. Diese gehen dann aber soweit ich weiss am Tabellenpuffer vorbei direkt auf die DB.

Gruss
Programmierhans

Edit: Zitat gekürzt

Ich denke, um eine logische und Physische Trennung der Daten zu bekommen werde ich die Daten für jeden Mandanten in eine extra Datenbank legen.

Die Frage wäre jetzt nur noch wie ich am sinnvollsten z.B. eine zentrale Adress-Tabelle in den einzelnen Datenbanken ansprechen kann.

Da war MySQL früher mit MyISAM unter Linux nicht schlecht - dort konnte man in jeder Datenbank einen Symlink auf eine Tabelle in einer anderen Datenbank erstellen. Man hatte nur keine Trigger, SP´s und Transaktionen 😃

Beim SQL Server kannst du ebenfalls ohne Probleme auf andere Datenbanken verweisen. Aber das kann man alles nachlesen.

Das wird schön übersichtlich.
Bei 100Mandanten und 50 Tabellen, was nicht viel ist, schlappe 5000 Tabellen oder 100 Datenbanken 👍

Kauf Dir ein SAP System 😃

Naja.. Ich habe Aktuell hier maximal 12 Mandanten-Dantenbanken mit je 428 Tabellen drin.
Macht am ende auch über 5000 Tabellen insgesamt... aber dafür getrennt in eben 12 Datenbanken 😃