Mandantenfähigkeit nachrüsten - Design?

[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.