# Frage zum Umgang mit DB-Daten



## WeirdAl (25. Apr 2007)

Huhu,
ich weiß, dass der Threadtitel nicht gerade gut gewählt ist . Jedoch stehe ich vor einem "Denkproblem". Ich stelle gerade die DB Anbindung meines Webprojekts von direkten Zugang via JDBC auf Hibernate um und komme ins Grübeln.

Ich habe zwei Tabellen a) User (pk:id,.....) und b) Briefmarken (pk:id,....). Normalerweise würde ich durch Fremdschlüssel eine Beziehung von User<->Briefmarken setzen und in einer dritten Tabelle die ids der Tabellen a und b über FKs abspeichern. 
Jedoch habe ich bislang einfach immer aus der DB die Daten direkt gelesen und geschrieben. Ich halte in meinem Projekt das Nutzerobjekt im Speicher und greife dann über die User-id direkt auf die Daten aus der Tabelle b) zu.
Jetzt wollte ich das umstellen, quasi in Hibernate eine one-to-many bzw. many-to-many Beziehung "einführen", aber jetzt komme ich zu meinem eigentlichen Denkproblem.

Angenommen: Nutzer A meldet sich am System an (Webapplikation, Client: Browser). Mit Hibernate wird jetzt im Userobjekt die Liste der Briefmarken gefüllt und der Nutzer kann diese Liste aufrufen und bearbeiten. Beendet der Nutzer über den Logout Button seine "Session" werden alle Daten erneut in die Datenbank geschrieben (neu erstellt, aktualisiert).

Das wäre der Idealfall. Was ist jedoch, wenn der Nutzer das Browserfenster schliesst und das System keine Rückmeldung erhält und die Daten nicht in die DB sichert? Was passiert wenn der Nutzer "gleichzeitig" sich im IE und in Opera anmeldet und Änderung vornimmt? Man könnte verhindern das er sich mehrmals anmelden kann, jedoch würde ich das nur ungern machen. In beiden Fällen wären die DB Daten nicht "korrekt".

Wie soll ich nun vorgehen? Ich habe nun die Möglichkeit (wie bisher), dass sobald der Nutzer eine Anfrage ans System hat die Daten direkt aus der Datenbank zu holen oder direkt reinzuschreiben und die Briefmarkenliste im Nutzerobjekt nicht anzulegen und somit keine Verbindung zwischen Tabelle a und b herzustellen. 
Im anderen Fall müsste sichergestellt werden, dass die Daten in der Session des Nutzers jederzeit konsistent sind. Das heisst sobald Änderungen an der Briefmarkenliste des Nutzerobjekts gemacht werden, müsste sichergestellt werden, dass diese Änderung bei einem "Absturz" des Programms (oder weg-x-en des Webbrowsers) noch in die Datenbank weggeschrieben werden.

Kann mir jemand evtl. kurz erklären, wie dies in einer Webapplikation oder einer normalen Applikation in Hibernate bzw. JDBC in der Praxis realisiert wird? Ich würde mich auch über Links freuen. 

Cu
Alex

P.S.: Danke das ihr das durchgelesen habt


----------



## Guest (25. Apr 2007)

WeirdAl hat gesagt.:
			
		

> Angenommen: Nutzer A meldet sich am System an (Webapplikation, Client: Browser). Mit Hibernate wird jetzt im Userobjekt die Liste der Briefmarken gefüllt und der Nutzer kann diese Liste aufrufen und bearbeiten. *Beendet der Nutzer über den Logout Button seine "Session" werden alle Daten erneut in die Datenbank geschrieben (neu erstellt, aktualisiert).*


Ich denke, hier ist das Problem begraben. Warum sollten die Daten, die bereits bearbeitet worden sind, erneut 
geschrieben werden bzw. warum erst zu einem so späten Zeitpunkt?

Der Benutzer holt sich seine Daten ab (Anzeige), bearbeitet sie (einzeln, oder mehrere gleichzeitig) und klickt
im Browser auf Speichern. Tut er dies nicht oder verlässt er die Seite, sind die Daten weg.
Die Daten für die Dauer der gesamten Browser-Session zu halten ist ein "vermeidbarer" Aufwand. Versucht der Benutzer 
aus einem anderen Browser heraus die Daten zu ändern, kriegt er eine Fehlermeldung, falls diese bereits von einer 
anderen "Arbeitsstation" aus geändert wurden (optimistic locking). Hibernate bzw. JPA bietet eine gute Unterstützung 
für optimistic locking (@Version Annotation) und entsprechende Exceptions beim Merge/Persist.

Alternative: Eine Art persistente Sessions, ein Puffer für Änderungen, der immer direkt beschrieben wird und nur
nach Bestätigung in den Datenbestand (also in die eigentlichen Daten des Benutzers) übernommen wird. Dieser 
Puffer verbleibt in der Datenbank auch über die Dauer der Session hinaus, so dass man zu einem späteren Zeitpunkt 
(nach erneutem Einlogen) den gleiche Stand der Bearbeitung zu sehen kriegt. Nachteil: Doppelte Datenhaltung 
und ein nicht zu vernachlässigender Mehraufwand solche Sessions zu verwalten und synchron zu halten.


----------



## WeirdAl (25. Apr 2007)

Huhu, danke für die Antwort 

Mir geht es unter Anderem darum, dass ich keinen "Sinn" darin sehe die Briefmarkenliste im Userobjekt zu halten, wenn diese Liste eh durch das sofortige speichern der Änderungen in der DB aktuell vorliegt.

Wobei, wenn ich die Liste im User-Objekt halte und direkt die geänderten Daten in dieser Liste sowie in der DB ändere , muss ich nicht bei jedem "Abruf" der Briefmarkenliste lesend auf die DB zuzugreifen (was ich ohne diese Liste im Userobjekt ja machen müsste). Das würde die DB schon n bissl entlasten. 

Das mit dem Optimistic Locking muss ich mir mal ansehen bzw. ich werd mich mal in Hibernate reindenken und beginnen die Mapping-files zu schreiben. Danke nochmals für den Denkanstoss

Cu
Alex


----------

