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
