Alternativen zu Beziehung über mehrere Datenbanken?

[Well]

Moin

Mal angenommen, ich würde gerne ein etwas größeres Projekt umsetzen; Dessen wesentliche Bestandteile könnten ein Portal, ein Forum und eine Wiki sein. Damit die Datenbank übersichtlich bleibt, dachte ich mir, man könnte ja eine Datenbank für das Forum, eine für die Wiki, eine für das Portal und eine für das Usermanagement Modul verwenden. Nun bräuchte aber z.B.: die Tabelle "threads" des Forums ja auch eine Beziehung zu den Accounts, da man ja wissen muss, von wem ein Thema / Beiträge / ... erstellt wurde. Da Beziehungen über verschiedene Datenbanken vom GORM ja noch nicht unterstützt werden, kann das ganze so auch nicht umgesetzt werden?! Wie könnte man soetwas dann umsetzen?

Dann noch eine andere Sache: Angenommen, man würde nun alles in eine Datenbank verlegen. Wie schaffe ich dann eine Beziehung zwischen einer Tabelle des Usermanagement-Modules und der eigenen Seite? Wenn man in die Beziehungs-Konfigurationsdatei der eigenen Seite die Beziehung schreibt, fehlt an der Stelle ja die entsprechende Tabelle in der Objekt-Konfigurationsdatei, da diese ja nur in der, des Usermanagement-Moduls existert. Wie löst man das dann?

Mit freundlichen Grüßen!

[dr.e.]

Hallo Well,

ich kann mich erinnern, dass wir das im Forum mal diskutiert hatten, finde die Stelle leider nicht mehr.

Da Beziehungen über verschiedene Datenbanken vom GORM ja noch nicht unterstützt werden, kann das ganze so auch nicht umgesetzt werden?! Wie könnte man soetwas dann umsetzen?

Die klassische Lösung ist, die Applikation mehrschichtig aufzubauen. Das bedeutet, dass du eine Kern-Komponente "Benutzer-Verwaltung" vorsiehst, die dir Informationen zum Benutzer zur Verfügung stellt, Login durchführen kann, etc. Diese - bzw. die Informationen des Nutzers - nutzt du dann in anderen Applikationen um z.B. Threads eines Benutzers auszulesen oder seine Detail-Seite im Forum anzuzeigen. Prämisse dabei ist, dass du - sofern du mit dem GORM arbeitest - in den konkreten Applikationen mit Stellvertreter-Objekten arbeitest. Das bedeutet, das du ein User-Objekt in deiner Foren-Anwendung modellierst, das jedoch nur aus einer Stellvertreter-ID (=der eigentlichen User-ID) besteht. Diese assoziierst du dann zum gewünschten Objekt und hast so die Möglichkeit, Applikationen in beliebige Datenbanken zu trennen.

Dann noch eine andere Sache: Angenommen, man würde nun alles in eine Datenbank verlegen. Wie schaffe ich dann eine Beziehung zwischen einer Tabelle des Usermanagement-Modules und der eigenen Seite?

Wie angesprochen, würde ich hier ein Stellvertreter-Objekt definieren, das lediglich das Mapping zwischen eigentlichem User-Objekt und den Applikations-Daten repräsentiert.

Wenn man in die Beziehungs-Konfigurationsdatei der eigenen Seite die Beziehung schreibt, fehlt an der Stelle ja die entsprechende Tabelle in der Objekt-Konfigurationsdatei, da diese ja nur in der, des Usermanagement-Moduls existert. Wie löst man das dann?

Hierzu kannst du die Konfiguration des UmgtManager / bzw. des GORM erweitern und die gewünschte zusätzliche Konfiguration einfach hinzuladen. Das stellt sich in der Praxis dann so dar, dass du in deiner Applikation eine Basis-Konfiguration einliest (z.B. die des UserManagement) und dann per addMappingConfiguration() oder addRelationConfiguration() weitere Konfigurationen der konkreten Applikation hinzulädst. Sofern du auf Stellvertreter-Objekte setzt, ist das quasi nicht mehr nötig.

Unter GenericORMapper kannst du die ursprüngliche Diskussion dazu einsehen. Im Thread GORM-Applikation für zentrale Datenhaltung findet sich noch einiges zu den Überlegungen einer zentralen Datenhaltung.

Ich hoffe, das hilft dir weiter.

[dr.e.]

Hallo Well,

konnte ich dir weiterhelfen oder brauchst du noch Hilfestellung zum Problem?

[Well]

Die klassische Lösung ist, die Applikation mehrschichtig aufzubauen. Das bedeutet, dass du eine Kern-Komponente "Benutzer-Verwaltung" vorsiehst, die dir Informationen zum Benutzer zur Verfügung stellt, Login durchführen kann, etc. Diese - bzw. die Informationen des Nutzers - nutzt du dann in anderen Applikationen um z.B. Threads eines Benutzers auszulesen oder seine Detail-Seite im Forum anzuzeigen. Prämisse dabei ist, dass du - sofern du mit dem GORM arbeitest - in den konkreten Applikationen mit Stellvertreter-Objekten arbeitest. Das bedeutet, das du ein User-Objekt in deiner Foren-Anwendung modellierst, das jedoch nur aus einer Stellvertreter-ID (=der eigentlichen User-ID) besteht. Diese assoziierst du dann zum gewünschten Objekt und hast so die Möglichkeit, Applikationen in beliebige Datenbanken zu trennen.

Moin!

Sorry, aber ich hatte in den letzten Tagen nicht wirklich Zeit mich damit zu beschäftigen, weswegen ich auch noch nicht geantwortet habe.

Nun zum Beitrag: Nochmal zum Verständis:
Ich erstelle also eine weitere Tabelle in den entsprechenden Datenbanken, diese dann als Stellvertretung dient, also für jeden registrierten Benutzer die ID speichert. Die Tabellen für die Themen, Beitäge usw. haben dann eine Beziehung zu diesem Stellvertreter. An die Benutzerdaten komme ich dann, indem ich im entsprechendem Manager / Controller / ... die ID des Benutzers von dem Stellvertreterobjekt auslese und anhanden dieser ID dann den Benutzer über den Manager des umgt Moduls lade?

Wenn das soweit stimmt habe ich es verstanden.

mfg

[dr.e.]

Hallo Well,

kein Problem, ich wollte nur sicher gehen, dass ich dich nicht zu sehr verwirrt habe.

Ich erstelle also eine weitere Tabelle in den entsprechenden Datenbanken, diese dann als Stellvertretung dient, also für jeden registrierten Benutzer die ID speichert.

Korrekt. Sofern du den GORM nutzt, hast du in einer Konfiguration den Benutzer in seiner vollen Ausprägung - z.B. so:

Code: Alles auswählen

[User]
FirstName = "..."
LastName = "..."
Username = "..."
Passwort = "..." 
...

und in der zweiten (=spezifische Applikation) nur noch einen Platzhalter:

Code: Alles auswählen

[User]

Die Tabellen für die Themen, Beitäge usw. haben dann eine Beziehung zu diesem Stellvertreter.

Korrekt. Du definierst in deiner konkreten Applikation dann einfach eine Beziehung vom jeweils gewünschten Objekt zum Benutzer. Z.B. so:

Code: Alles auswählen

[User2Entry]
SourceObject = "User"
TargetObject = "Entry"
Type = "..."

An die Benutzerdaten komme ich dann, indem ich im entsprechendem Manager / Controller / ... die ID des Benutzers von dem Stellvertreterobjekt auslese und anhanden dieser ID dann den Benutzer über den Manager des umgt Moduls lade?

Korrekt. Im umgekehrten Fall hast du vielleicht die Daten des eingeloggten Nutzers in der Session und kannst so über die Beziehung "User2Entry" die relevanten Objekte laden, die der Nutzer in der Applikation angezeigt bekommen soll.

Solltest du noch Fragen zur konkreten Implementierung haben, dann immer her damit!

Viele Grüße,
Christian

[Well]

Dann dankeschön für die Hilfe.

Habe es nun erfolgreich umgesetzt.