Hallo zusammen,

ich habe folgende Frage zu Hibernate. Wir würden gerne Hibernate innerhalb einer unternehmensweiten EnterpriseApplication einsetzen.

Als Datenbanksystem steht DB2 auf OS390 zur Verfügung. Da ich nicht weiss ob jeder mit DB2 auf OS390 vertraut ist, noch eine kurze Info.

Wir haben über 200 Kunden, die alle diese Anwendung nutzen sollen. Die Tabellen sind zwar für alle Kunden gleich, besitzen aber einen anderen DB-Qualifier. Dieser stellt sich wie folgt dar:

Kunde001.Stammdaten
Kunde002.Stammdaten
...
...
Kunde200.Stammdaten

KundeXXX wäre also der Qualifier und Stammdaten die jeweilige Tabelle. Für jeden Kunden bestehen ca 150 Tabellen. Insgesamt also 30.000 Tabellen.

Jetzt zur eigentlichen Frage. Muss ich in der XML-Datei alle Tabellen mit den jeweiligen Qualifiern beschreiben, oder reicht es aus nur die Tabellen zu beschreiben und den Qualifier zur Laufzeit, also erst bei Zugriff, anzuhägen?
In meinen Augen wäre es unpraktikabel 30.000 Tabellen zu beschreiben. Dadurch würde doch auch ein riesen Overhead entstehen. Hoffentlich gibt es für dieses Problem eine elegante Lösung, die ihr mir etwas näher erklören könntet.

Vielen Dank im Voraus.

Gruß
Martin

Das ist neuer Rekord fuer das "interessanteste" Design einer Datenbank... Natuerlich sollte die Anwendung 150 Tabellen haben, und die Unterscheidung zwischen Kunden anders hergestellt werden (virtuelle Datenbank, parameterisierbare Views, etc.) Wenn das eine existierende Datenbank ist, den Verantwortlichen feuern, falls noch nicht geschehen. Wenn das eine neue Idee ist, bitte verwerfen (allerdings sichert sowas auch Arbeitsplaetze).

Man kann eine Configuration auch zur Laufzeit erstellen. Dabei kann man auch properties setzen.
Ich kennde DB2 nicht, aber wenn die Namensbezeichnung durch ein Schema oder Catalog in Hibernate repräsentiert wird, kannst Du ein Defaut Schema/Catalog festlegen.

-> Hibernate Reference 3.4
hibernate.default_schema

Gruß Sebastian

Hallo christian,

auf dem ersten Blick mag es so aus sehen. Wir betreiben ein Datewarehouse für 200 Kunden. Innerhalb der Tabellen des Kunden hat er wieder seine jeweiligen Kunden.

Du kannst es dir in etwas so vorstellen.

Nehmen wir mal an, wir betriebn das DWH für die Telekom. Jeder unserer Kunden ist die Telekom der jeweiligen Stadt. Also haben wir 200 Städte und dahher auch die 200 Qualifier. In den Tabelen sind die Telekomkunden aus der jeweiligen Stadt. Über die Qualifier erreichen wir also ein Trennung.

In Tabelle Kunde1.Kundendaten sind also alle Kunden aus Stadt 1 usw.

Sicherlich ist es auch möglich, alle Kunden in eine Tabelle zu packen und eine STATD_ID zu benutzen, aber aufgrund von Ausfall etc (Hochverfügbarkeit) hat man es so realisiert. Es sind auch nicht alle Städte in einem DB2 System. Davon gibt es mehrere. Dies würde wir aber über verschiedene DataSources lösen.

Soviel zur Begründung des Datenbankdesigns.

Ich würde mich aber freuen, wenn du auch noch eine Antwort auf meine eigentliche Frage hättest, oder ist die Frage mit dem Thema "Schema" schon hinreichend beantwortet.

Viele Grüße
Martin

Wenn das eine Applikations-Instanz ist, ist das definitiv der falsche Ansatz. Alleine das Booten von Hibernate wuerde mehrere Stunden dauern. Probleme wie "Verfuegbarkeit" und "Performanz" haben nicht das geringste mit der Struktur des logischen Modells zu tun, das System sollte horizontal so verteilt sein dass es fuer die Anwendung keinen Unterschied macht - transparent eben. Man verteilt ein System horizontal _nicht_ dadurch dass man mehrere logische Tabellen fuer eine Entity aufbaut.

Wenn das 200 Applikations-Instanzen sind ist die Loesung schon im Thread beschrieben worden. Ausserdem gibt es eine NamingStrategy um dynamisch Tabellen/Spalten-Namen fuer eine SessionFactory hinzubiegen.