Daten persistent speichern

[JMarkus]

Hallo,
ich stehe mal wieder vor einer Frage und hoffe ihr könnt mir helfen. ???:L

Angenommen ich möchte eine Anwendung zur Fahrzeugverwaltung erstellen. Dann habe ich eine Vielzahl von bspw. Auto-Objekten. Diese Auto-Objekte haben Daten wie z. B. Hersteller, Modell, Kennzeichen, Farbe, usw.

Nun möchte ich diese "Daten" natürlich dauerhaft abspeichern. Hierbei stellt sich schon mal die Frage ob man nur die reinen Daten (also "Opel" -> "Astra"...) oder das gesamte Auto-Objekt abspeichern muss. Eine weitere Frage wäre, welches Mittel (serielle Datei, XML-Datei, (embedded) DB) man dazu verwenden sollte bzw. was heute best practise ist.

Ich bin auf eure Beiträge gespannt

 

[Tassimmo]

Hallo,

also das Objekt an sich kannst du nicht abspeichern. Du wirst die reinen Daten nehmen müssen, sie irgendwo abspeichern, und beim erneuten Laden ins Programm wieder als Objekt darstellen müssen, da Java-Objekte nur zur Laufzeit "existieren".

Zum Testen deiner Anwendung kannst du zunächst deine Rohdaten als Textdatei abspeichern. Wenn die Anwendung irgendwann mal größer wird und auch richtig verwendet wird, würde ich dir eine Datenbank empfehlen, auf die du dann mit JPA (zum Beispiel auch mit Hibernate Framework) zugreifst.

 

[javanick]

Hallo,

zum Abspeichern von "gesamten" Objekten gibt es das Interface Serializable.
Dazu auch im (englischen) Wikipedia-Artikel: Serialization
Hier ein einfaches Tutorial dazu und hier das zugehörige Kapitel in "Java ist auch eine Insel"

Die ganzen Objekte werden nicht serialisiert, sondern "nur" die Attribute, die nicht als statisch und nicht als transient markiert sind.

Wenn Du allerdings riesige Datenmengen hast, würde ich wie Tassimmo eine Datenbank verwenden.

 

[JMarkus]

Danke für eure Antworten. Dass also nur die Daten der Objekte gespeichert werden habe ich jetzt kapiert

Bei der anzuwendenden Speichertechnik bin ich mir allerdings noch nicht sicher was ich nehmen soll. Die von javanick beschriebene Serialisierung ist ja nur eine Möglichkeit. Diese hat jedoch auch ihre Nachteile wie z. B. ein proprietäres Format, Probleme bei der Deserialisierung wenn Strukturänderungen am Programm vorgenommen wurden, usw.

Mir schwebt da schon eher die Variante einer HSQLDB vor mit Zugriff über bspw. JPA (wie von Tassimmo angerissen). Da ich allerdings nicht tausende von Datensätzen habe scheint mir der Aufwand hierfür etwas hoch. Gibt es nicht noch weitere, einfache und gut unterstützte Möglichkeiten?

 

[strußi]

die objektinhalte in eine txt zu speichern und diese wieder einzulesen ist eine einfache lösung

 

[Thallius]

Wenn du nur ein paar Einträge hast würde ich es als XML speichern. Aber wenn Du Dich einmal in z.B. sqlite eingearbeitet hast, dann geht es deutlich schneller dieses zu benutzen als erstmal eine XML Schnittstelle zu definieren und das Datenformat zu erzeugen etc. Ich würde immer eine DB nehmen da man ja auch gar nicht weiß ob das Programm nicht doch mal größer wird und dann muss man eh auf eine DB umbauen. Und wie gesagt. Wenn man es kann (Und etwas zu können ist ja eigentlich nie verkehrt) dann dauert es nicht länger eine DB zu implementieren als etwas anderes zu machen.

Gruß

Claus

 

[JMarkus]

Ich würde immer eine DB nehmen

Genau das schwebte mir auch vor. Zu der Frage welche DB man nehmen kann, gibt es hier einen interessanten Artikel
Eingebettete Datenbanken | iX

Nun stellt sich nur noch die Frage, wie man das Problem der objektrelationalen Abbildung am besten löst. Ist JPA da die einzige Möglichkeit? Bestimmt nicht oder...?! Wie bekomme ich also am besten (und einfachsten) die Objekte in eine relationale DB?

 

[Thallius]

Also wenn es dein erstes DB Projekt ist, dann würde ich gar nicht mit irgendeinem Framework arbeiten sondern es einmal selber machen. So lernst du was eine Normalisierung ist, wie man DB Tabellen richtig aufbaut und man intelligente Queries macht.

Sprich du erstellst Dir für jede Klasse einen Konstruktor der dein Objecte aus einem Datensatz erzeugt und eine Methode die das Object in die DB schreibt bzw updated.

Gruß

Claus

 

[Tassimmo]

Das wäre tatsächlich auch das, was ich vorgeschlagen hätte.
Du kannst von Anfang an JPA verwenden, es ist, einmal verstanden, sehr einfach anzuwenden und zu adaptieren. Allerdings verwendest du dabei für den eigentlichen Datenbankzugriff bereits vorgegebene Methoden, musst deine eigenen SQL-Befehle schreiben und deinen Zugriff sowie deine Anbindung selbst aufbauen. Es ist wichtig zu verstehen, wie so ein DB-Zugriff an sich funktioniert, damit du auch reagieren kann, wenn mal irgendwas schief läuft.

Im Hintergrund verwendet JPA eigentlich auch nichts anderes als JDBC, nur siehst du davon dann weniger.

 

[JMarkus]

Kennt jemand ein gutes Tutorial für JPA oder kann jemand Beispielcode posten für das oben angefangene Beispiel "Fahrzeugverwaltung" (Auto-Objekte)? Ich kann JPA irgendwie noch nicht so recht einordnen bzw. abgrenzen von z. B. Hibernate, EclipseLink. Brauche ich solch ein Framework oder geht es auch mit Java-Boardmitteln (z. B. JPA)? Und wie??

 

[BRoll]

Wie wäre es noch mit einer objektorientierten Datenbank wie zb. db4o?
Dann spart man sich doch einiges an Konvertierung und es passt besser, da Java auch OOP ist!

 

[Thallius]

HM ich sage ich würde es selber machen und Du sagst "Will ich auch" und dann kommst du doch mit JPA.

Wo ist denn jetzt das Problem ein Object in eine DB zu schreiben? Dafür brauche ich doch kein JPA sondern ein paar Codezeilen.

Gruß

Claus

 

[JMarkus]

Meine Antwort bezog sich auch mehr auf den Post von Tassimmo und "Will ich auch" habe ich nie geschrieben!
Sicher kann man auch alles selber coden, danach wegwerfen und JPA lernen aber den Aufwand wollte ich mir halt sparen und lieber gleich "richtig" loslegen.
Und natürlich ist es ein Problem Objekte aus der objektorientierten Welt in eine relationale DB zu schreiben. Es ist sogar ein sehr bekanntes Problem: Object-relational impedance mismatch :lol:

 

[Thallius]

Das ist ja super theoretisiert. Also ein Objekt das ein Auto beschreibt in einer DB abzubilden ist kinderkram und habe ich in der Form zigfach gemacht. Und dafür braucht kein Mensch JPA.

Aber ich bin halt einfach zu oldschool hier in dem Thread. Mach wie du willst

 

[JMarkus]

Das mit dem Auto-Objekt war ein vereinfachtes BEISPIEL um die Problematik möglichst kurz und verständlich zu beschreiben. Natürlich steht da schon eine größere Anwendung hinter, sodass es durchaus Sinn macht sich mit JPA o. ä. zu beschäftigen.

Aber was will mir einer von der Praxis erzählen, der die Theorie schon nicht verstanden hat?? :noe:

Vielleicht hat ja noch jemand eine Antwort auf die ursprüngliche Frage in Kommentar 11. Der Tipp mit db4o ist im Übrigen auch nicht schlecht. Werd ich mir mal genauer anschauen.