Eine Tabelle in mehreren Datenbanken

[Morphie]

Hi,

wir werden wohl demnächst ein Projekt mit einer Firebird DB starten.
Das Projekt soll wahlweise auf unterschiedliche Datenbestände (Mandanten) zugreifen können, z.B.:
Kunden
Lieferanten
Artikel
->Preise
usw.

Unser bisheriger Ansatz war, dass wir für jeden Mandanten eine eigene Datenbank anlegen.
Jetzt soll es aber möglich sein, dass sich alle Mandanten z.B. die Tabelle "Kunden" teilen. (falls gewünscht)
Das ganze soll möglichst flexibel gestaltet werden, damit man auf die entsprechenden Kundenwünsche schnell eingehen kann.

Meine bisherigen Ideen:
1. Alle Daten in EINE Datenbank schreiben und für jede Tabelle ein Feld "MandantID" führen. Hat den Nachteil, dass wir bei jedem Query die MandatenID mit angeben müssen.
2. Alle Daten in EINE Datenbank schreiben, aber auf unterschiedliche Tabellen (mit Präfix) aufteilen. (z.B. Mandant1_Kunden, Mandant2_Kunden usw.)
Hat den Nachteil, dass wir bei jedem Query die Tabelle ermitteln müssen.
3. Warten bis Firebird Cross-Table-Queries untersützt ;-)

Punkt 1 + 2 brauchen dann zusätzlich noch eine Verknüpfungstabelle.

Wie würdet ihr sowas machen?

[grl]

Also ich würde die erste Methode wählen. Methode 2 finde ich unübersichtlich und auch nicht wirklich elegant, Methode 3 hängt ein bisschen vom geplanten Fertigstellungstermin ab.

Die MandantID permantent mitzuführen sollte im Zeitalter der Objektorientierung nicht wirklich ein Problem sein...

Gruß
Luggi

[mkinzler]

Zitat:

3. Warten bis Firebird Cross-Table-Queries untersützt

Seit Version 2.5 kann man ja in PL ja schon auf andere datenbanken zugreifen.

1) wäre für mich eine saubere Lösung
Man kann die MandantenID ja als Parameter entsprechend vorbelegen oder als verbindungsspezifische Kontextvariable

[exilant]

Ich würde bei der Lösung mit einer Datenbank pro Mandant bleiben. Das halte ich für die sauberste Variante. Gemeinsam benötigte Tabellen würde ich mittels Replikation auf die Mandanten verteilen. Daten von Mandanten zu mixen ist allerdings nicht eben "Best Practice".

[Morphie]

Zitat:

Zitat von mkinzler (Beitrag 1120886)

...
Man kann die MandantenID ja als Parameter entsprechend vorbelegen oder als verbindungsspezifische Kontextvariable

Sowas habe ich noch nie gemacht. Hast du da vielleicht ein kleines Beispiel für? (IBDAC)

Zitat:

Zitat von grl (Beitrag 1120885)

...
Die MandantID permantent mitzuführen sollte im Zeitalter der Objektorientierung nicht wirklich ein Problem sein...
Gruß
Luggi

Stimmt, das sollte kein Problem sein.

[Neutral General]

Würde es auch so machen wie mkinzler es vorgeschlagen hat.
Firebird (2.5) unterstützt mittlerweile ja datenbankübergreifende Queries.

Und selbst mit Firebird 2.1 haben wir hier in unserem Programm 1 Datenbank pro Mandant. (Geht alles über Replikation).

[Jumpy]

Aus unserer Praxis kann ich sagen, dass man beide Wege gleichzeitig gehen kann.
Wir haben große Kunden (Konzerne mit mehreren Unterfirmen) die mit/als mehrere Mandanten auftreten.
Die kriegen somit mit ihren mehreren Mandanten eine eigene DB.

Dann gibt es aber Kunden, die sind nur ein Mandant und wollen aber aus Sicherheitsgründen eine eigene DB. Dann kriegen Sie sie auch. Da aber die DB-Struktur überall gleich ist, wird trotzdem die MandantID mitgeführt (auch wenn sie in dem Fall ja nicht nötig ist).

Und es gibt Kunden die sind einer oder mehreren Mandanten und denen ist es egal, sich eine DB zu teilen (ist natürlich auch billiger) und da ist die mitgeführte MandantID und sehr sauberes Arbeiten natürlich sehr wichtig.

[mjustin]

Zitat:

Zitat von Jumpy (Beitrag 1120899)

Und es gibt Kunden die sind einer oder mehreren Mandanten und denen ist es egal, sich eine DB zu teilen (ist natürlich auch billiger) und da ist die mitgeführte MandantID und sehr sauberes Arbeiten natürlich sehr wichtig.

Bei Konzernen oder sonstwie verbundenen Unternehmen ist das auch günstig, z.B. für Ad-Hoc-Abfragen über mehrere Mandanten.

Man muss auch nicht zwangsweise in jeder Tabelle auch die Mandaten-ID speichern - reine Detailtabellen (Auftragspositionen zum Beispiel) enthalten einen Fremdschlüssel auf eine Mastertabelle (Auftragskopf), hier braucht man dann eine Mandanten-ID.