Mandantenfähigkeit nachrüsten - Design?

[DeddyH]

Ich trage mich mit dem Gedanken, eine DB mandantenfähig zu gestalten. Leider habe ich damit einige Probleme bzgl. des DB-Designs. Am besten schildere ich mal ein Beispiel: gegeben seien folgende Tabellen

Code:

TBL_Kunde
=========
ID
Name
...


TBL_Artikel
===========
ID
Bezeichnung
...


TBL_Kunde_Artikel
=================
Kunden_ID
Artikel_ID

Die klassische m:n-Beziehung also. Wenn ich nun also sowohl Stamm- als auch Bewegungsdaten an einen Mandanten koppeln möchte, müsste das ja dann etwa so aussehen (zusätzliche Tabellen):

Code:

TBL_Mandant
===========
ID
Name
...


TBL_Mandant_Kunde
=================
Mandant_ID
Kunden_ID


TBL_Mandant_Artikel
===================
Mandant_ID
Artikel_ID

Die Zuordnungstabelle zwischen Kunde und Artikel müsste dann einen zusätzlichen Fremdschlüssel auf den Mandantensatz bekommen, oder? Genau hier liegt jetzt mein Problem: was mache ich, wenn ich die Zuordnung von z.B. einem Artikel zu einem Mandanten aufhebe? Dann habe ich in der Kunden_Artikel-Tabelle ja evtl. Datensatzleichen. Das würde ich gern vermeiden, nur wie? ON DELETE CASCADE scheint mir eine Möglichkeit zu sein, allerdings ist das ja nicht ganz ungefährlich.

Bin für jeden Denkanstoß dankbar.

[mkinzler]

Ich würde einen Kunden immer fest an einen Mandaten binden. Sollte er wirklich Kunde zweier Mandanten sein, wird er halt zweimal angelegt. das erleichtert dir die Sache, weil du nur eine Tabelle erweitern musst

[DeddyH]

Das wäre eine Möglichkeit, wenn nicht in der Kunden-Tabelle ein UNIQUE-Index existieren würde, auf den ich nicht so einfach verzichten kann. Aber Danke, ich denke nochmal drüber nach.

[Sir Rufo]

Hallo,

die Frage stellt sich ja, ob es überhaupt übergreifende Beziehungen zwischen den Artikel und den Mandanten gibt.

Ich würde sagen eher nicht, denn wenn Mandant 1 an einem Artikel etwas ändert (Bezeichnung o.ä.) dann will Mandant 2 das ja nicht unbedingt auch haben!

also müssten deine Stammdaten-Tabellen eigentlich nur um das Feld MandantenID erweitert werden zzgl. einer Tabelle Mandanten.
Fertig, dann nur noch das ganze entsprechend verdrahten, damit überall die MandantenID berücksichtigt wird.

Denn am wichtigsten ist eine 100% Trennung der Daten zwischen den Mandanten.

cu

Oliver

[mkinzler]

Erweitere den doch um den Mandant

[Sir Rufo]

Zitat:

Zitat von DeddyH

Das wäre eine Möglichkeit, wenn nicht in der Kunden-Tabelle ein UNIQUE-Index existieren würde, auf den ich nicht so einfach verzichten kann. Aber Danke, ich denke nochmal drüber nach.

Ja so ein UNIQUE-Index muss natürlich dann auch die Mandanten-Nummer beinhalten ...

[DeddyH]

Also, es geht hier nicht wirklich um Kunden und Artikel, das war nur ein Beispiel. Mein "Kunde" enthält ein Feld "Kürzel", das DB-weit eindeutig sein muss, da er am Frontend darüber identifiziert wird.

Probleme über Probleme...

[mkinzler]

Aber man muss am Frontend doch vorher einen "Mandanten" auswählen. Wenn du den Index um diesen erweiterst ist diese Kombination wieder eindeutig, auch wenn das Kürzel mehtfach vorkommt.

[Sir Rufo]

Zitat:

Zitat von DeddyH

Also, es geht hier nicht wirklich um Kunden und Artikel, das war nur ein Beispiel. Mein "Kunde" enthält ein Feld "Kürzel", das DB-weit eindeutig sein muss, da er am Frontend darüber identifiziert wird.

Probleme über Probleme...

Wenn Du uns aber nur ein abstraktes Beispiel lieferst, dann bekommst Du aber auch nur abstrakte Antworten zurück.

Man muss halt unterscheiden, was sind exklusive Daten pro Mandant und was sind übergreifende Daten.

cu

Oliver

[DeddyH]

Nachdem ich gerade noch einmal nachgedacht habe, stelle ich fest, dass ich mit dem Begriff "Mandantenfähigkeit" wohl etwas übertrieben habe. Im klassischen Sinne hättet Ihr beide völlig recht, aber was mir vorschwebt, ist einfach nur eine Filterung der Sichtbarkeit der Daten. Um also bei den Begrifflichkeiten zu bleiben: die Stammdaten sind weiterhin konzernweit gültig und sollen lediglich einem oder mehreren Mandanten zugeordnet werden können. Heißt also, wenn ein Mandant einen Stammdatensatz ändert, wirken sich diese Änderungen auf alle Mandanten aus. Das widerspricht natürlich dem Mandantenmodell, ist aber hier so gewollt.

Sry, dass ich mich falsch ausgedrückt hatte.

[mkinzler]

Dann sollte es reichen, die m:n-Beziehung wie von dir aufgezeigt zu modellieren. Am Rest der DB müsste dann ja nichts geändert werden.

[DeddyH]

Danke, ich denke auch, dass das so die beste Variante ist.

[joachimd]

kleiner Denkanstoß, der in eine etwas andere Richtung geht:
Du hast eine Applikation, welche nicht Mandantenfähig ist (Kunde, Artikel, ... plus zentrale Tabellen, wie PLZ, BLZ usw).
1. Schritt: Jeder Mandant bekommt sein eigenes Eco-System, also eine unabhängige Datenbank (DBMandant1, DBMandant2, ...)
2. Schritt: Du baust eine Einstiegs-DB auf (DBZentral, zB mit Mandanten-Auswahl-Tabelle und den Pfaden zu bzw Namen der Datenbanken - ja nach System).
3. Schritt: Du extrahierst die zentralen Tabellen in die Zentral-DB (zB um die PLZ, BLZ nicht jedesmal pflegen zu müssen).
4. Schritt: Da nun in den Mandanten diese Tabellen fehlen, ersetzt Du diese durch Views auf die Tabellen der Zentral-DB - fertig (create view plz as select * from zentraldb.plz)

Alles, was Du in der Applikation nun ändern musst, ist ein neues Startfenster, das sich zur ZentralDB verbindet und die Mandantenauswahl anbietet. Ist ein Mandant ausgewählt, verbindest Du den Rest (also alles wie bisher) mit der Mandanten-DB.

Auf diese Weise habe ich schon einige mit der heißen Nadel gestrickten Applikationen umstellen lassen und innerhalb kürzester Zeit Mandanten-fähig gemacht.

Forgot: Du musst natürlich auch eine kleine Mandanten-Verwaltung einbauen (neuer, leerer Mandant anlegen, Mandant löschen, Mandant bearbeiten usw).

[edit]
habe gerade gesehen, dass du ja schon etwas relativiert hast...aber ich lasse das posting trotzdem als Anregung, falls einer so was sucht;) [/edit]

[DeddyH]

Soweit wollte ich jetzt nicht gehen, aber der Ansatz ist schon ganz schön tricky, das werde ich mir auf jeden Fall mal merken.
Herzlichen Dank :thumb:.

[mkinzler]

Zitat:

1. Schritt: Jeder Mandant bekommt sein eigenes Eco-System, also eine unabhängige Datenbank (DBMandant1, DBMandant2, ...)

Fände ich zu umständlich

[joachimd]

Zitat:

Zitat von mkinzler

Zitat:

1. Schritt: Jeder Mandant bekommt sein eigenes Eco-System, also eine unabhängige Datenbank (DBMandant1, DBMandant2, ...)

Fände ich zu umständlich

kommt auf das DBMS an .. ich präferiere aus bekannten Gründen ADS, und da kann ich dann einfach per XCopy eines leeren Mandaten (bzw Backup-Restore mit "MetaOnly" eines normalen Mandanten) einen neuen erstellen ... ohne allzuviel Arbeit, da die DB auch nicht am Server attached wird.
Aber zum Glück ist und bleibt das Geschmackssache <g>

[nahpets]

Hallo DeddyH,

bei mir sieht Mandantenfähigkeit im Prinzip so aus:

• Jeder Mandant hat seine eigene Datenbank (bzw. ein eigenes Datenbankschema, wenn mehrere Mandanten den gleichen Datenbankserver benutzen).
• Für gemeinsame Daten (Steuerdaten) gibt es ein Schema, dass in jeder Datenbank einmal vorhanden ist und mandantenübergreifend genutzt wird (Bankleitzahlen, Postdaten...) können hier untergebracht werden. Steuertabellen für die Mandantenauswahl, also alles dass, was das Programm selbst zum prinzipiellen Funktionieren benötigt.

Alles was mandantenspezifisch ist und sich prinzipiell von Mandant zu Mandant unterscheiden kann, kommt in das Schema des Mandanten, auch wenn hierdurch ggfls. Redundanzen entstehen können. Kein Mandant kann/darf Daten ändern, die auch andere Mandanten betreffen könnten. Hierdurch ist der Umzug eines Mandanten auf einen anderen Datenbankserver immer möglich. Er benötigt das "Steuerschema" und sein Datenschema, d. H. seine Daten sind immer eindeutig identifizierbar und separat sicherbar.
Bei einer Mischung von mehrere Mandanten in einem Schema mit gemeinsamer Nutzung von Tabellen, müsste man ja hier erstmal "seine" Daten zusammensuchen und dann noch streng von den Daten der anderen Mandanten trennen. Dies dürfte bei mehreren Mandanten eine nicht mehr so ganz triviale Angelegenheit sein. Ob die Mischung mehrere Mandanten in einem Schema mit gemeinsamer Tabellennutzung noch als revisionssicher zu bezeichnen ist, vermag ich nicht zu beurteilen.

Stell' Dir mal vor, alle Mandanten benutzen ein Schema und nun hat einer der Mandanten seine Daten zersemmelt, wie willst Du da mit vertretbarem Aufwand ein Restore hinbekommen, wenn Du Teilmengen sämtlicher Tabellen ersetzen musst, aber keinesfalls die Daten anderer Mandanten verändern darfst.

Gehen wir mal davon aus, Du benutzt ADO als Schnittstelle, dann benötigst Du zwei AdoConnections in Deinem Programm, eine für das "Steuerschema" und eine für das Datenschema. Da es datentechnisch eigentlich keine Verbindung zwischen den beiden Schemata geben darf, ist die Trennung nicht problematisch. Daten (Bankleitzahlen...) aus dem "Steuerschema" können in dem Programm "nur" als Nachschlagtabelllen angeboten werden. Werden solche Daten ins Datenschema übernommen, so werden sie dort redundant abgelegt und nicht in Form von Fremdschlüsselbeziehungen. Sind die Fremdschlüsselbeziehungen zwingend erforderlich, so müssen die Steuerdaten (Bankleitzahlen...) Teil des Datenschemas werden, da hier mandantenspezifische Unterschiede auftreten können. Eine Normalisierung der Daten findet nur auf Mandantenebene statt und nicht mandantenübergreifen.

So tricky ist das Ganze dann eigentlich doch nicht :wink:

[DeddyH]

Hallo Stephan, da hast du natürlich recht, aber das ist in meinem Fall nicht die Anforderung. Es geht vielmehr darum, die Bewegungsdaten auseinander halten zu können, da reicht mein im Ausgangspost geschildertes Design vollkommen aus.