ubuntuusers.de

Ich weiß, dass es sich dabei im ein (soweit ich weiß) sehr weitläufiges und in java (wenn ich das richtig interpretiere) nicht allzu unkompliziertes Thema handelt, aber meine Versuche, das zu umschiffen und meinen eigenen Pseudo-Datenbanktreiber (mit ner ArrayList und einer extra Klasse als Tabellenzeilen) hat nicht so ganz funktioniert.

Nachdem ich nicht darauf vertraue, dass ich jetzt durch Zufall und mit viel Glück eine ordentliche Lösung mit einem guten Treiber im Web finde (was für mich ganz gut klingt ist das: http://www.zentus.com/sqlitejdbc/ ), würde ich da gerne auf eure Erfahrung und Tipps verlassen.

Ich suche eine Lösung, mit der ich mehrere Tabellen in einer Datei speichern kann, also nicht serverbasiert, und das am besten noch in UTF-8, nachdem die Datenbank universell unter Linux, Mac OS, FreeBSD (also generell alle POSIX Systeme auf denen Java läuft) und Windows einsetzbar sollte.

Schonmal ein großes Danke für eure Hilfe!

Superdreadnought hat geschrieben:

Nachdem ich nicht darauf vertraue, dass ich jetzt durch Zufall und mit viel Glück eine ordentliche Lösung mit einem guten Treiber im Web finde (was für mich ganz gut klingt ist das: http://www.zentus.com/sqlitejdbc/ ), würde ich da gerne auf eure Erfahrung und Tipps verlassen.

Ich suche eine Lösung, mit der ich mehrere Tabellen in einer Datei speichern kann, also nicht serverbasiert, und das am besten noch in UTF-8, nachdem die Datenbank universell unter Linux, Mac OS, FreeBSD (also generell alle POSIX Systeme auf denen Java läuft) und Windows einsetzbar sollte.

Dann bist du schon genau richtig gelandet 😉

sqlite ist sehr weit verbreitet. Unter anderem verwenden es Amarok, Gajim und Digikam zum Speichern von Daten. Python 2.5 integriert sqlite sogar direkt in die Standardbibliothek, weil es so verbreitet ist.

hast du mit dem treiber von zentus schon erfahrungen gemacht?
es gibt für SQLite einige java-treiber, die ich nicht alle ausprobieren müssen will.

Superdreadnought hat geschrieben:

hast du mit dem treiber von zentus schon erfahrungen gemacht?
es gibt für SQLite einige java-treiber, die ich nicht alle ausprobieren müssen will.

Nein, ich versuche Java nach Kräften zu vermeiden, und programmiere lieber mit Python. Deswegen kann ich dir bei der Auswahl des JDBC Treibers nicht helfen. Ich dachte, dir geht es darum, ob sqlite an sich geeignet ist. Sorry 😳

für was musst du dich denn bitte entschuldigen?!
allein, dass du mir gesagt hast, dass ich mit SQLite die richtige wahl getroffen habe, hat mir sehr geholfen (schränkt die wahl von immerhin 221 datenbanktypen für die es JDBC-Treiber gibt auf eine ein).

Und warum nimmst Du nicht die bei Java mitgelieferte Datenbank Java DB? Da brauchst Du Dich auch nicht mit 3rd party JDBC Treiber rumzuschlagen.

dentaku hat geschrieben:

Und warum nimmst Du nicht die bei Java mitgelieferte Datenbank Java DB?

Hab mir JavaDB grad ma angeschaut ... da zitier ich einfach ma aus der readme meines wrappers für SQLite

What:  SQLite 3.3.x JDBC Driver
Who:   David Crawshaw <david@zentus.com>
When:  2006
Why:   Because Derby is bloated, HSQLDB has too many capital letters
       in its name and I don't have the time to maintain a full Java
       port of SQLite.
How:   BSD License (dig in)

(bloated == aufgebläht)

SQLite erscheint mir da zukunftssicherer, nachdem es eben nicht nur für java ist. aber danke für den tipp!

Viel wichtiger ist es, dass Du Deine Anwendung unabhäbig von der verwendeten Datenbasis schreibst. Pures JDBC und Du kannst jederzeit die darunter liegende DB austauschen.

Und apropos bloated: wenn 2 MB für eine vollwertige Datenbank zu aufgebläht für Dich ist ... und ausserdem ist Java DB 100% pure Java - somit Platformunabhängig und läuft auf jeder JVM.

Beachte auch SQL Features That SQLite Does Not Implement im Vergleich zu Derby support for SQL-92 features.

dentaku hat geschrieben:

Viel wichtiger ist es, dass Du Deine Anwendung unabhäbig von der verwendeten Datenbasis schreibst. Pures JDBC und Du kannst jederzeit die darunter liegende DB austauschen.

ack.

dentaku hat geschrieben:

und ausserdem ist Java DB 100% pure Java

Das gerade macht es ja bloated *duck* 😉

dentaku hat geschrieben:

- somit Platformunabhängig und läuft auf jeder JVM.

Gilt für sqlite auch.

dentaku hat geschrieben:

Beachte auch SQL Features That SQLite Does Not Implement

Das einzige, was sich davon in einer kleinen Datenbankanwendungen wirklich schmerzlich äußern könnte, ist das Fehlen von Fremdschlüsseln und eventuell noch der limitierte JOIN Support. Es wäre allerdings auch erstaunlich, wenn jemand in einer kleinen Anwendung davon exzessiven Gebrauch machen würde.

Was man allerdings an Java DB beachten sollte, ist die Sprachgebundenheit. Wechselt man später mal die Sprache, ist die DB nicht mehr ansprechbar, ohne vorher konvertiert zu werden. Allerdings besitzt jede verbreitete Sprache sqlite Bindings.

Lunar hat geschrieben:

Was man allerdings an Java DB beachten sollte, ist die Sprachgebundenheit. Wechselt man später mal die Sprache, ist die DB nicht mehr ansprechbar, ohne vorher konvertiert zu werden. Allerdings besitzt jede verbreitete Sprache sqlite Bindings.

Genau darauf wollte ich mit Zukunftssicherheit raus.

EDIT: Dazu kommt bei Java DB hinzu, dass ich keine ordentlichen tutorials gefunden hab (was bei SQLite schnell ging) und ausserdem man dazu genauso wie bei SQLite ne jarfile saugen und ins projekt integrieren muss (obwohls seit JDK (1.)6 angeblich von haus aus dabei is. (Wenn du da ein paar Infos für mich hättest wär ich dir dankbar. Dann werd ich morgen nochma Java DB gegen SQLite abwägen - momentan tendiere ich aber eher zu SQLite).

Superdreadnought hat geschrieben:

für was musst du dich denn bitte entschuldigen?!
allein, dass du mir gesagt hast, dass ich mit SQLite die richtige wahl getroffen habe, hat mir sehr geholfen (schränkt die wahl von immerhin 221 datenbanktypen für die es JDBC-Treiber gibt auf eine ein).

SQLite hmm, nehme ich persönlichauch sehr gerne, aber kommt immer drauf an was du machst.

Bei Bacula (Backup Programm) z.B. wird in der Doku dazu nicht empfohlen SQLite im Produktiv Einsatz zu nehmen, da es anscheind häufig vorgekommen ist das SQLite auf einmal ab einer bestimmten größe schnell Inkosistent wird, und nicht mehr geht.

Wenn du aber oft Backups machst und du keine Hunderte von GBs an daten speicherst sollte das denke ich alles okay sein.

Ansonsten wenn du Zukunftssicher und Ausgereift haben willst gibt es doch wie immer die zwei default Databases:
PostgreSQL oder MySQL.

kann man, um das jetzt mal unprofessionell auszudrücken, mit MySQL direkt in dateien schreiben?

Falls Du das meinst was ich glaube was Du meinst: Nein. ☺

Firebird ist noch eine Datenbank bei der man alles in einer Datei speichern lassen kann, die auch über Plattformgrenzen hinweg portabel ist.

um nochmal darauf zurückzukommen, kennt jemand ein ordentliches tutorial für Derby (Java DB)? Ich hab nur tutos für die serverbasierte variante gefunden, aber für mein projekt kann ich nur dateibasiert gebrauchen.

EDIT: Noch ne dumme Frage:
Wie integriere ich eine jar-File (z.B. die Datenbanktreiber-jar für Derby¹ oder SQLite), die im jre/lib/ext-Ordner meines JDKs rumlungert, so in die jar-File meiner Anwendung, dass ich das Programm auf jedem Rechner mit JRE laufen lassen kann?

¹Was das angeht hab ich immernoch nicht kapiert, ob Derby nun im JDK (1.).6.0 mit drin ist oder nicht. Hier steht, es wäre dabei, aber ordentlich laden kann ich den Treiber nicht.

Superdreadnought hat geschrieben:

um nochmal darauf zurückzukommen, kennt jemand ein ordentliches tutorial für Derby (Java DB)? Ich hab nur tutos für die serverbasierte variante gefunden, aber für mein projekt kann ich nur dateibasiert gebrauchen.

Es gibt aus Sicht der Applikation, die Derby als embedded DB benutzt nur zwei Dinge zu beachten:
- richtige JDBC Treiberklasse benutzen (org.apache.derby.jdbc.EmbeddedDriver)
- passenden Pfad für die Datenbank in die Connection-URL packen.
- (eventuell create=true in die Connection-URL mit aufnehmen)

Wirf doch mal einen Blick auf den passenden Abschnitt im Developerguide bzw auf den Teil Connecting to databases im gleichen Dokument.

Ich fand die Derby bzw. JavaDB Doku eigentlich recht umfangreich, wenn man sich auch manchmal die Informationen etwas daraus zusammensuchen muss.