Frage zu Datenmodel / Zugriff

[RaoulDuke]

Hallo,

ich bin bei der Entwicklung eines Datenbankmodels auf ein paar Kleinigkeiten gestossen die ich hier mal ansprechen möchte um da den besten Weg herauszufinden. Ich fange dazu mal mit einem einfachen Beispiel an, das auf das für die Problematik notwendige reduziert ist:

Mal angenommen ich habe eine Datenbankstruktur für ein Forum. Ich habe eine Tabelle 'users' mit den Werten 'id' und 'username'. Dann noch eine Tabelle 'posts' mit den Werten 'id', 'user_id', 'text'.

Ich würde dann hingehen und 2 Beans erstellen, eine Bean 'user' mit den Feldern 'id' und 'username', und eine Bean 'post' mit den Feldern 'id', 'user_id' und 'text'. Dann entsprechende Klassen die mir einen User oder Post laden, speichern, updaten, etc können.

Jetzt möchte ich vielleicht eine View haben die mir alle Posts darstellt. Dafür würde ich dann wohl erstmal alle Einträge aus der 'posts' Tabelle laden. Ich hätte dann also eine Collection mit einer Hand voll 'post' Beans.

Die kann ich jetzt theoretisch darstellen, aber ich möchte natürlich zu jedem Posting auch den Usernamen haben, der halt nicht in der 'post' Bean drin ist. Und da gibt es ja jetzt verschiedene Wege das zu realisieren:

- Ich könnte mir zu jeder 'post' Bean auch die entsprechende 'user' Bean laden. Das würde die Zahl der SQL Abfragen verdoppeln, und ich hätte evtl. viel mehr Daten abgerufen als ich brauche. In der Realität hat die Tabelle 'users' evtl. ja wesentlich mehr Felder als hier im Beispiel.

- Ich könnte der 'post' Bean ein Feld Username geben. Ich habe mir den Sourcecode von JForum (http://freshmeat.net/projects/jforum/) heruntergeladen und dort nach dieser Problematik gesucht. Dort gibt es genau diesen Fall, und dort ist es so realisiert das die Post Bean den Usernamen nochmal enthält.

Generell finde ich dieses Vorgehen ganz ok, allerdings entsprechen dann die Beans nicht mehr dem Datenbankmodell. Der Grund, den Usernamen in der 'post' Bean zu haben, liegt nicht in der Datenhaltung, sondern rein in der Anforderung des Views. Wenn ich den Usernamen in die 'post' Bean hole könnte ich auch gleich noch alle anderen Werte aus der User Tabelle in die 'post' Bean holen.

- Mein bisheriges Vorgehen sah immer so aus das ich mich an Beans halte die genau so aussehen wie die zugehörige Tabelle. Jedenfalls fürs schreiben und interne Verarbeiten der Daten. Für diverse Views habe ich separate View Beans für gewisse Anforderungen erstellt die dann evtl. mehr Felder enthalten als die Tabelle selbst. Das ist prinzipiell einfach zu handhaben, hat aber wieder den Nachteil das mehr als eine Klasse auf eine Tabelle zugreift. Aber ich kann mir auch irgendwie nicht vorstellen das man jeglichen Zugriff auf eine Tabelle sinnvoll über eine einzige Klasse kapseln kann. Speziell wenn man Auswertungen über mehrere Tabellen laufen lassen muss um irgendwelche Werte zu erhalten.


Also, wie seht Ihr das? Bin für jeden Denkanstoss dankbar.

Grüsse,

Sven

 

[AlArenal]

Ich würde die Beans nicht als 1:1 Abbildung ihrer Tabellen konzipieren, sondern nach den Regeln der Kunst der Objektorientierung. Demnach würde das Post-Bean ein Feld User haben, welches eine User-Bean-Instanz enthält.

Zugriffe auf die DB sollten gecached werden. Dazu gabs letztens noch nen netten Artikel. Oder man tut sich den Driss nicht an und beschäftigt sich mit fertigen ORMs (Hibernate & Co).

http://today.java.net/pub/a/today/2006/07/13/lazy-loading-is-easy.html

 

[RaoulDuke]

Kling im Prinzip logisch, aber auch nur wenn man wirklich einen Cachingmechanismus laufen hat. Für eine kleinere Applikation würde man aber evtl. nicht so einen Aufwand treiben wollen gleich Hibernate zu benutzen, ohne Caching würde die Vorgehensweise aber gleich die Zahl der SQL Abfragen verdoppeln.

In anderen Programmiersprachen würde man sich z.B. ja auch deutlich schwer tun so einen Cachingmechanismus zu finden, dann ich z.B. an Perl oder PHP Scripte denke die nicht threaded laufen und wo nach einem Aufruf alle Daten wieder aus dem Speicher raus sind. Ich würde halt lieber bei der Vorgehensweise blieben, wie man es macht, wenn man es nicht mit Hibernate erschlägt.

 

[AlArenal]

Für eine kleinere Applikaktion wäre die Verwendung eines ORM ein Klacks.

 

[RaoulDuke]

Für eine kleinere Applikaktion wäre die Verwendung eines ORM ein Klacks.

Ich möchte aber evt. kein Hibernate benutzen, weil es mir zu oversized erscheint, weil ich es nicht einschätzen kann, weil ich lieber SQl Querys direkt an meine Datenbank schicke als erst herauszufinden wie man das mit HSQL macht, etc.

 

[AlArenal]

Für kleinere Anwendungen hast du mit HQL wie oben hast du mit HQL nichts am Hut. Ansonsten bedient es sich zeimlich ähnlich wie SQL. Der Vorteil, wenn man sich mit Hibernate & Co. beschäftigt ist auch, dass man sich nicht auf Bacuhgefühle verlassen muss, sondern Kosten und Nutzen abwägen kann.
Nie damit gearbeitet zu haben ist ne ziemlich unzureichende Basis, um sich auf eine unkonkrete Aussage wie "weil es mir zu oversized erscheint" zu verlassen. Und ich gehe davon aus, dass du nicht immer nur so Kleinkram machen willst.
Ansonsten hast du ja oben Link zum Lazy Loading und hier noch einen zum Selbstentwickeln eines ORM: http://www.ambysoft.com/essays/persistenceLayer.html

Ansonsten bieten gerade kleine einfache Anwendugen ne gute Möglichkeit sich mal in diverse Tools einzuarbeiten, um sie so für spätere Verwendung zu evaluieren. Wenn man damit wartet, bis man ein richtig komplexes Szenario vor sich hat, erschlät einen das oft.