Die meisten Fragen, die sich um den Titel dieses Beitrags drehen, betreffen die Ausführung von Hibernate oder einer anderen Zugriffsschicht in einem OSGi-Container. Oder sie fragen danach, wie man die Datenquelle in einem OSGi-Container zum Laufen bringt.
Meine Fragen betreffen die Auswirkungen der OSGi-Modularität auf die Struktur der Datenbank selbst. Genauer gesagt:
- Wie kann man die Struktur einer Datenbank selbst modular gestalten, so dass wenn wir ein Modul laden - z.B. Kontaktmanagement - wird das Schema aktualisiert wird, um Tabellen aufzunehmen, die speziell mit diesem Modul verbunden sind?
- Wie wirkt sich der vorgenannte Ansatz auf die Beziehungen aus?
Ich denke, die zweite Frage ist die interessantere. Nehmen wir an, dass Kontaktmanagement und Projektmanagement zwei verschiedene OSGi-Module sind. Jedes hätte seinen eigenen Satz von Tabellen im Schema. Was aber, wenn wir auf der Datenbankebene modulübergreifende Beziehungen zwischen zwei oder mehr Tabellen herstellen müssen? Vielleicht möchten wir eine Liste der Projekte sehen, an denen ein bestimmter Kontakt arbeitet oder gearbeitet hat.
Jede Lösung scheint dazu zu führen, dass die verschiedenen Module zu viel übereinander wissen müssen. Wir könnten in die Projektmanagement-Spezifikation schreiben, dass dieses Modul eine Quelle für Kontakte erwartet, und diese Erwartung dann durch Dienste, Schnittstellen, pub-sub usw. abstrahieren. Es scheint jedoch eine Menge Arbeit zu sein, eine fest verdrahtete Beziehung zwischen den zugrunde liegenden Tabellen der beiden Module zu vermeiden.
Was nützt es, oben und in der Mitte modular zu sein, wenn wir diese Modularität zwangsläufig durch Beziehungen zwischen Tabellen unten aufbrechen müssen? Sind Denormalisierung und ein Servicebus wirklich eine gesunde Lösung?
Haben Sie eine Idee?
Ich danke Ihnen.
