Datenhaltung ohne Server

[JavaMann]

Hallo spezis,
Ich möchte ein kleines Programm schreiben wo man Adressdaten von ca. 100 Personen aufnehmen kann.
Was bietet sich dort als Datenhaltung an? Ne txt ist mir zu blöd. Könnt ihr mir eine elegantere Lösung vorschlagen. Danke im Vorraus.

 

[madboy]

Dann nimm ne Datenbank :wink:

 

[JavaMann]

Welche? Bzw. Wie? Ich bin ein grünschnabel.

 

[madboy]

Hmmm. Datenbanken gibts viele. Recht weit verbreitet ist mySQL.
Aber wenn du überhaupt keine Ahnung von Java und Datenbanken haben solltest, wäre wohl eine Textdatei das Beste zum Üben und Lernen.

Alternativ bietet sich auch Serialisierung an. Ist noch einfacher bzw. weniger Code zum Schreiben.

Lies dir am besten ein paar Kapitel in http://www.galileocomputing.de/openbook/javainsel6/ durch zu dem Thema, das dich interessieren würde (Serialisierung, Dateien oder Datenbank)

 

[SaschaLR]

Hallo,

wenn du keine DB nehmen willst oder kannst, dann kanst du es ja mal mit xml versuchen. Wie wäre es z.B. mit jdom?

www.jdom.org

Obwohl ich dir auch eher zu einer DB raten würde... versuch HSQLDB zu nehmen, da brauchst du nix ausser der .jar zu installieren.

www.hsqldb.org

Gruß, Sascha

 

[Guest]

Bei 100 Datensätzen würde einfache Serialisierung reichen.

@SuppressWarnings("unchecked")
private static <TElementType extends Serializable,TListType extends List<TElementType>> TListType loadList(File file) 
       throws IOException, ClassNotFoundException
{
   TListType list = null;
   if(file.exists())
   {
      ObjectInputStream v_Stream = new ObjectInputStream(
                                       new InflaterInputStream( 
                                         new BufferedInputStream(new FileInputStream(file))
                                       )
                                   );
      list = (TListType)v_Stream.readObject();
      v_Stream.close();
   }
   return list;
}

private static <TElementType extends Serializable,TListType extends List<TElementType>> void storeList(File file, TListType list) 
              throws IOException
{
   assert list != null;
   ObjectOutputStream v_Stream = new ObjectOutputStream(
                                     new DeflaterOutputStream(
                                       new BufferedOutputStream(new FileOutputStream(file))
                                     )
                                 );
   v_Stream.writeObject(list);
   v_Stream.close();
}

 

[Guest]

Ups, korrektur, der Code war Blödsinn.

   @SuppressWarnings("unchecked")
   private static <TElementType extends Serializable> List<TElementType> loadList(File file)
         throws IOException, ClassNotFoundException
   {
      List<TElementType> list = null;
      if (file.exists())
      {
         ObjectInputStream v_Stream = new ObjectInputStream(new InflaterInputStream(new BufferedInputStream(
               new FileInputStream(file))));
         list = (List<TElementType>) v_Stream.readObject();
         v_Stream.close();
      }
      else
      {
         list = new ArrayList<TElementType>();
      }

      return list;
   }

   private static <TElementType extends Serializable> void storeList(File file, List<TElementType> list) throws IOException
   {
      assert list != null;
      ObjectOutputStream v_Stream = new ObjectOutputStream(new DeflaterOutputStream(new BufferedOutputStream(
            new FileOutputStream(file))));
      v_Stream.writeObject(list);
      v_Stream.close();
   }

 

[Wildcard]

Gerade bei solchen Daten ist Serialisierung unbrauchbar.
Was passiert wenn irgendwann das Format geändert wird?
Mein Vorschlag wäre EMF, JaxB, HSQL, JavaDB oder H2.

 

[Guest]

Gerade bei solchen Daten ist Serialisierung unbrauchbar.
Was passiert wenn irgendwann das Format geändert wird?
Mein Vorschlag wäre EMF, JaxB, HSQL, JavaDB oder H2.

Was für Format wird geändert?

Ich vermute, er möchte nur eine simple Adressverwaltung schreiben. Die Datenmenge ist dabei so gering,
dass das ganze auf einen Schlag in den Speicher geladen werden kann. Extra dafür ein RDBMS zu verwenden
wäre hier etwas über's Ziel hinaus geschossen. Das sind vermutlich nicht mehr als zwei, drei Tabellen (Person,
Adresse + sonst noch etwas). Wie auch immer, war nur ein Vorschlag. Sollte die Anwendung mal grösser
werden, kann er immer noch auf ein RDBMS umsatteln.

 

[Wildcard]

Gerade bei solchen Daten ist Serialisierung unbrauchbar.
Was passiert wenn irgendwann das Format geändert wird?
Mein Vorschlag wäre EMF, JaxB, HSQL, JavaDB oder H2.

Was für Format wird geändert?

Die Felder der Klassen, die Struktur der Datenklassen, whatever.
Serialisierung ist unflexibel wie nichts und gerade solche Sachen wie Adressdaten will man von jeder älteren Version wieder importieren können.

 

[Guest]

Gerade bei solchen Daten ist Serialisierung unbrauchbar.
Was passiert wenn irgendwann das Format geändert wird?
Mein Vorschlag wäre EMF, JaxB, HSQL, JavaDB oder H2.

Was für Format wird geändert?

Die Felder der Klassen, die Struktur der Datenklassen, whatever.
Serialisierung ist unflexibel wie nichts und gerade solche Sachen wie Adressdaten will man von jeder älteren Version wieder importieren können.

Ein Konverter ist in fünf Minuten geschrieben. Änderst du das Datenbankschema, musst du ebenfalls ein Migrationsscript
schreiben. Bei JAXB und sonstigen XML basierten Sachen um so mehr. Komm schon, ich brauche ein Argument,
welches mich wirklich überzeugt für 100 Datensätze einer simplen Anwendung eine Datenbank zu verwenden.

 

[Wildcard]

Ich zitiere einfach mal aus der Javainsel:

Der klassische Weg von einem Objekt zu einer persistenten Speicherung führt über den Serialisierungsmechanismus von Java über die Klassen ObjectOutputStream und ObjectInputStream. Die Serialisierung in Binärdaten ist aber nicht ohne Nachteile. Schwierig ist beispielsweise die Weiterverarbeitung von Nicht-Java-Programmen oder die nachträgliche Änderung ohne Einlesen und Wiederaufbauen der Objektverbunde. Wünschenswert ist daher eine Text-repräsentation. Diese hat nicht die oben genannten Nachteile.

Ein weiteres Problem ist die Skalierbarkeit. Die Standard-Serialisierung arbeitet nach dem Prinzip: Alles, was von einem Basisknoten aus erreichbar ist, wird in den Datenstrom geschrieben. Ist der Objektgraph sehr groß, steigt die Zeit für die Serialisierung und das Datenvolumen an. Verglichen mit anderen Persistenz-Konzepten, ist es nicht möglich, nur die Änderungen zu schreiben. Wenn sich zum Beispiel in einer sehr großen Adressliste die Hausnummer einer Person ändert, muss die gesamte Adressliste neu geschrieben werden – das nagt an der Performance.

Auch parallele Änderungen können zum Problem werden, da die Serialisierung über kein transaktionales Konzept verfügt. Während der Serialisierung sind die Objekte und Datenstrukturen nicht gesperrt, und ein anderer Thread kann derweil alles Mögliche modifizieren. Der Entwickler muss sich selbst auferlegen, während des Schreibens keine Änderungen vorzunehmen, damit der Schreibzugriff isoliert ist. Auch wenn es während des Schreibens ein Problem (etwa eine Ausnahme) gibt, kommt ein halbfertiger Datenstrom beim Client an.

Objektserialisierung ist der einfachste, aber auch der schlechteste Weg Daten zu persistieren. Meiner Meinung nach hat Serialisierung ausserhalb von RMI (und einigen anderen Anwendungsfällen) keinerlei Existenzberechtigung.
Dann lieber noch der XMLEncoder.

 

[Guest]

...
Objektserialisierung ist der einfachste, aber auch der schlechteste Weg Daten zu persistieren. Meiner Meinung nach hat Serialisierung ausserhalb von RMI (und einigen anderen Anwendungsfällen) keinerlei Existenzberechtigung.
Dann lieber noch der XMLEncoder.

Ich finde, dass XML in einer reinen Java-Umgebung, bis auf die ganzen Konfigurationsdateien in JEE (Deployment
descriptoren, Webservicese etc.) keine Daseinsberechtigung hat. Was soll man da mit diesen aufgemotzten
ASCII-Dateien.

Ich vermute, wenn wir zusammen arbeiten würden, würden wir täglich über grundsätzliche Design-Entscheidungen
streiten (sowas kann sehr lustig sein, wenn sich die Gemüter "aufheizen" :wink: ). Natürlich gebe ich dir recht, dass
eine Datenbank (fast) immer die bessere Lösung ist, aber verdammt, hier geht es nur um eine simple Anwendung
mit ca. 100 Datensätzen. Das ganze ist schneller auf der Festplatte, als du Festplatte sagen kannst, selbst wenn
du es rückwärts schreibst. :lol:

 

[Wildcard]

Wenn dir nicht klar ist wozu man XML wohl brauchen könnte, hast du die letzten Jahre verpennt.
Insofern würde eine solche Diskussion auch sehr schnell vorbei sein (wenn wir zusammen arbeiten würden).
Falls es dir entgangen sein sollte: Java wird zukünftig sogar inline XML enthalten :wink:

Dafür ein XML Binding zu generieren dauert keine 5 Minuten und schon kann man mit einfachem XSLT oder Ecore Mappings Exportfilter einbauen.
Und um's nochmal zu sagen: Wenn schon serialisieren, dann mit dem XMLEncoder (geht genauso schnell wie Objektserialisierung).

 

[Guest]

Wenn dir nicht klar ist wozu man XML wohl brauchen könnte, hast du die letzten Jahre verpennt.
Insofern würde eine solche Diskussion auch sehr schnell vorbei sein (wenn wir zusammen arbeiten würden).
Falls es dir entgangen sein sollte: Java wird zukünftig sogar inline XML enthalten :wink:

Dafür ein XML Binding zu generieren dauert keine 5 Minuten und schon kann man mit einfachem XSLT oder Ecore Mappings Exportfilter einbauen.
Und um's nochmal zu sagen: Wenn schon serialisieren, dann mit dem XMLEncoder (geht genauso schnell wie Objektserialisierung).

Nöö, ich habe nix verpennt. Trotzdem sind es aufgemotzte ASCII-Dateien.

Jezt aber langsam. Du willst tatsächlich für irgendwelche trivialen Sachen XSLT oder gar ECore verwenden?
Das Format der Ausgabe des XMLEncoders ist auch ziemlich unleserlich (im Prinzip eine Anweisungsliste)
und muss ebenfalls komplett gelesen werden, es sei dann du willst bei diesem Riesenprojekt noch XPath
hinzunehmen. :lol:

 

[Wildcard]

Das Format der Ausgabe des XMLEncoders ist auch ziemlich unleserlich (im Prinzip eine Anweisungsliste)
und muss ebenfalls komplett gelesen werden,

Aber wohl doch besser als ein binäres Format :wink:

Und nicht vergessen, die alt bekannte Swing Warnung die in gewohnter Manier vor dauerhafter Persistierung mittels Objektserialisierung warnt ...

Warning: Serialized objects of this class will not be compatible with future Swing releases. The current serialization support is appropriate for short term storage or RMI between applications running the same version of Swing. As of 1.4, support for long term storage of all JavaBeansTM has been added to the java.beans package. Please see XMLEncoder.

 

[Guest]

Das Format der Ausgabe des XMLEncoders ist auch ziemlich unleserlich (im Prinzip eine Anweisungsliste)
und muss ebenfalls komplett gelesen werden,

Aber wohl doch besser als ein binäres Format :wink:

Dann doch lieber ein "richtig binäres", sprich Datenbank.

Und nicht vergessen, die alt bekannte Swing Warnung die in gewohnter Manier vor dauerhafter Persistierung mittels Objektserialisierung warnt ...

Warning: Serialized objects of this class will not be compatible with future Swing releases. The current serialization support is appropriate for short term storage or RMI between applications running the same version of Swing. As of 1.4, support for long term storage of all JavaBeansTM has been added to the java.beans package. Please see XMLEncoder.

Die gilt für Swing-Komponenten. Deren interner Aufbau könnte sich ändern und somit
auch das Format bei der Serialisierung (die Daten, die serialisiert werden). :bae:

Wollten wir die Diskussion hier nicht auch noch fortsetzen? (der Gast dort bin ebenfalls ich)
Attribute in Interfaces möglich?

Gruß,
semi :wink: (wo zur Hölle ist mein Passwort)

 

[Wildcard]

Dann doch lieber ein "richtig binäres", sprich Datenbank.

Eben

Die gilt für Swing-Komponenten. Deren interner Aufbau könnte sich ändern und somit
auch das Format bei der Serialisierung (die Daten, die serialisiert werden). :bae:

Darum geht's ja. Sobald sich an der Struktur etwas ändert fliegt die Deserialisierung auf die Nase, daher ist diese Methode einfach Mist.

 

[Murray]

Gerade bei solchen Daten ist Serialisierung unbrauchbar.
Was passiert wenn irgendwann das Format geändert wird?
Mein Vorschlag wäre EMF, JaxB, HSQL, JavaDB oder H2.

Was für Format wird geändert?

Die Felder der Klassen, die Struktur der Datenklassen, whatever.
Serialisierung ist unflexibel wie nichts und gerade solche Sachen wie Adressdaten will man von jeder älteren Version wieder importieren können.

Ein Konverter ist in fünf Minuten geschrieben.

Ganz so trivial ist so ein Konverter aber doch nicht - Objektserialisierung lebt doch davon, dass eine Klassen den Code zur Serialisierung und Deserialsierung komplett in sich trägt - also ist die Klasse auch die einzige Stelle, in der sich dieses Wissen befinden sollte. Da man in einer VM normalerweise schlecht zwei verschiedene Versionen einer Klassen haben kann, muss also entweder die neue Version der Klasse eine Fallunterscheidung machen und das alte Format ebenfalls verstehen (was die Klasse aufbläht), oder es muss eine weitere Instanz geben, die mit dem Serialisierungsformat der alten Version umzufgehen weiss (obwohl das ja eigentlich ein Implementierungsdetail der Klasse selbst ist).

Für die persistente Speicherung würde ich immer eine von der eigentlichen Datenklasse unabhängige Instanz vorsehen - und ob die jetzt mit einer Datenbank, mit XML, mit einem selbstdefinierten Binärformat oder mit einem Persistenzframework wie Hibernate arbeitet, ist eigentlich wumpe - sofern es nicht weitere Randbedingungen gibt. Und gerade weil sich diese Randbedingungen ändern können, ist es doppelt sinnvoll, die Persistenzfunktionalität in einer von der eigentlichen Datenklasse getrennten Stelle anzusiedeln.

 

[Tellerrand]

Für die persistente Speicherung würde ich immer eine von der eigentlichen Datenklasse unabhängige Instanz vorsehen - und ob die jetzt mit einer Datenbank, mit XML, mit einem selbstdefinierten Binärformat oder mit einem Persistenzframework wie Hibernate arbeitet, ist eigentlich wumpe - sofern es nicht weitere Randbedingungen gibt. Und gerade weil sich diese Randbedingungen ändern können, ist es doppelt sinnvoll, die Persistenzfunktionalität in einer von der eigentlichen Datenklasse getrennten Stelle anzusiedeln.

Das kann man theoretisch auch mit der Serialisierung, wenn man die zu speichernden Klassen erst in der Persistenzschicht erweitert und erst in dieser Schicht Serializeable implementiert.
... Nunja, kann auf Dauer aber auch ne Menge mehr Arbeit sein.

Ich denke da hat der Fragesteller dann doch selber die Qual der Wahl.
Vielleicht wird er ja niemals einen Konverter brauchen.