Moeglichkeiten zum Speichern von Daten

[daflowjoe]

Hallo Leute,

mich wuerde mal interessieren wie man im professionellen Umfeld Daten speichert.

Ich kenne die folgenden Moeglichkeiten:

- Textdatei / CSV
- Serialisierte Objekte
- Datenbank

Ich habe teilweise "viele" Datenaetze (ca 10000). Eine Serialisierung waere fuer mich am bequemsten, Allerdings befuerchte ich, dass dies zu unperformant sein koennte.

Welche Methoden wuerdet ihr aus design -und performancetechnischer Sicht bevorzugen?

 

[Ark]

Ehrlich: das ist eine viel zu allgemeine Frage.

Ich habe momentan ein Projekt, da sind fast 40000 Datensätze drin, und ich verwende so etwas wie CSV. In meinem Fall reicht das eben vollkommen aus. In deinem Fall könnte derselbe Ansatz völlig ungeeignet sein, selbst mit weniger Datensätzen.

Es kommt eher darauf an, ob die entsprechende(n) Datei(en) genau das und genau so abbildet/en, was und wie du es eben benötigst. Falls du schon das nicht weißt, solltest du dir erst einmal darüber im Klaren werden. Falls du es aber schon weißt, solltest du vielleicht sagen, was du speichern möchtest. Möglicherweise gibt es für deine Aufgabe schon standardisierte Formate, an die du dich halten könntest/solltest.

Serialisierung ist meines Erachtens eine ziemlich schlechte Möglichkeit, Daten persistent zu speichern.

Ark

 

[ARadauer]

Sollen mehere Benutzer auf die gleichen Daten zugreifen? Datenbank
Ist die Strutkur sehr einfach, flach? CSV

 

[daflowjoe]

Also kontreter:

Ich moechte Buchungssaetze auswerten. Ich habe Datenstrukturen in Form von Listen, Buchungstabellen, Buchungsreports etc. die aber auch unterschiedliche Formate haben.
Salopp koennte man einfach sagen Listen und Tabellen.

Momentan sollen diese nur jeweils fuer einen User abgespeichert werden, (Staendiges Bearbeiten der Daten) Es sind aber auch mehrere "Profile angedacht", wo jede Strukur beliebig oft abgespeichert werden muss,

Warum sollte man keine Serialisierung verwenden?

 

[nillehammer]

Warum sollte man keine Serialisierung verwenden?

Ich persönlich finde Serialisierung als "poor man's persistence" garnicht schlecht, weil leicht zu programmieren. Doof ist nur, dass die Datenstruktur nur von Java interpretiert und geschrieben werden kann.

 

[hüteüberhüte]

mich wuerde mal interessieren wie man im professionellen Umfeld Daten speichert.

Datenbank, oder das hier noch gar nicht erwähnte XML...

 

[Bernd Hohmann]

Warum sollte man keine Serialisierung verwenden?

Wenn sich da in den letzten 10 Jahren nichts geändert hat: bei der Serialisierung einer Klasse wird eine Prüfsumme über die Komponenten einer Klasse errechnet und diese Prüfsumme wird bei der Objektserialisierung mit abgespeichert.

Dh. wenn Du in dem zu serialiserbaren Objekt (in der Regel eine Klasse) die Signatur durch zufügen/ändern/löschen einer Variablen oder zufügen/ändern/löschen einer Methode änderst wirst Du bei der deserialisierung gegen die Wand laufen.

Ich kann mich noch dumpf entsinnen, dass man das durch eine fixe SerialNumber für die Klasse und dann die Versionsunterschiede durch überschreiben von readObject(...) ausgleichen konnte.

Wenn Du tief in die Objektserialisierung von Java einsteigen möchtestr ist das ein gangbarer Weg.

Ansonsten würde ich sowas über Properties oder eine eigene Konstruktion erledigen.

Bernd

 

[daflowjoe]

Was ist eigentlich mit Hibernate? Ist das zu aufwendig fuer 150h Anwendung? Oder gibt es gaengige Bibliotheken die zum Beispiel eine ArrayList mit Objeken in XML serialisieren etc? Oder programmiert man das fuer jede Collection von Hand?

 

[nillehammer]

Hibernate oder noch abstrakter JPA ist ja nur eine Abstraktion der hier schon genannten Speicherung in Datenbanken. Ist auf jeden Fall eine gängige Variante. Ich mach das recht gerne. Es ist zwar anfänglich ein wenig Aufwand (das ganze Entity-Mapping und die DAOs). Aber dafür hat mein keine Sorgen mit konkurrierenden Zugriffen, inkonsistenten Daten nach abgebrochenen Transaktionen usw.

 

[Spacerat]

Serialisierung ist nicht gerade der beste Weg für persistente Daten. Ein Teil der Problematik wurde, wenn auch nicht so ganz korrekt, schon genannt.
1. Serialisierbare Objekte nebst ihren zur Serialisierung vorgesehenen Membern müssen Serializable implementieren.
2. Bevor ein Objekt in einen Stream serialisiert wird, wird dort zunächst der voll qualifizierte Klassenname und eine Prüfsumme hinein geschrieben und zwar für das Objekt selber und all seinen zu serialisierenden Member. Die Prüfsumme kann von der Klasse definiert werden (serialVersionUID) oder man lässt sie automatisch aus der Prüfsumme des Klassenbytecodes von der JVM berechnen.
3. Lässt man die Prüfsumme berechnen, lassen sich die serialisierten Daten nur von Versionsgleichen JVMs wieder lesen (Major-, Minorversion stehen im Bytecode) und man darf an der Klasse nichts mehr ändern, was die Prüfsumme des Bytecodes ändert wodurch alle bisher serialisierten Daten ungültig werden.
4. Die Deklarierung einer serialVersionUID ermöglicht, dass man alles an der Klasse ändern darf ausser die Daten, die bisher serialisiert wurden. Da darf nichts mehr hinzugefügt oder entfernt werden. Ferner lassen sich solche Objekte auch auf Versionsungleichen JVMs lesen, sofern dort eine entsprechende Klasse mit identischen Namen, serialVersionUID und serialisierten Membern existiert.

Serialisierung eignet sich deswegen (wenn überhaupt) eher für's Netzwerk als zur Speicherung in Dateien. "poor mans persistence" trifft's unheimlich. Ist einfach zu implementieren aber übelst zu warten. Die Dateien die bei einer Serialisierung entstehen sind wegen der zusätzlichen Speicherung der Klassennamen und Prüfsummen aller serialisierten Objekte und Unterobjekte natürlich stets wesentlich grösser.