SQLite oder RDBMS als Datei(nicht Client/Server)

[schmeckzilla]

Hallo,

ich suche eine SQL-Datenbank für die ich keinen Server installieren muss. Alle Daten sollen in einer Datei sein. Auf diese möchte ich per JDBC und SQL zugreifen.

Beim Googeln bin ich auf SQLite (http://www.sqlite.org) gestoßen. Hat damit schon jemand Erfahrugnen gemacht? Gibt es andere/bessere Datenbanksysteme die alles in einer Datei ohne einen extra zu installierenden Server speichern?

Die Datenmengen, die die Datenbank bewältigen muss, sind nicht groß. Meine Applikation soll ein virtuelles Trainingsbuch sein. Maximal 1-3 Einträge pro Tag.

Eine relationale Datenbank möchte ich auf Grund der besonderen Abfragemöglichkeiten haben.

Tschaui
Daniel

 

[AlArenal]

HSQLDB, Derby, Suchfunktion des Forums, ....

 

[schmeckzilla]

Hallo,

habe ich sogar gemacht. :shock:

Zu SQLite habe ich nicht wirklich was brauchbares im Forum gefunden. Eine Frage zu SQLite, die keiner beantwortet hat und eine Antwort, dass es SQLite gibt und HSQLDB auch csv kann.

Das beantwortet meine Fragen nicht. Sorry.

Auf Derby bin ich nicht von alleine gestoßen. Werde ich mir mal anschauen.

Ich möchte eine Datenbank in einer Datei ohne RDBMS in der ich mehrere Tabellen ablegen kann und auf die ich per SQL/JDBC zugreifen kann. Kann HSQLDB das auch, oder nur csv Dateien?

 

[AlArenal]

Ich möchte eine Datenbank in einer Datei ohne RDBMS in der ich mehrere Tabellen ablegen kann und auf die ich per SQL/JDBC zugreifen kann. Kann HSQLDB das auch, oder nur csv Dateien?

Du willst ne Datenbank und SQL mit JDBC, aber ne RDBMS willste nicht? Wie passt das zusammen?

HSQL legt normalerweise pro Datenbank eine Datei an, optional kann das auch eine CSV-Datei sein. Ansonsten gibts auch JDBC-Treiber speziell für CSV-/Excel-/Sonstwas-Dateien.

HSQLDB und Derby sind nur zwei Vertreter der Fraktion der in Java geschriebenen In-Process-Datenbanken, es gibt da noch ein paar mehr, manchen von denen fehlt dann auch der Server-Modus, der aber gerade in der Entwicklungsphase sehr nützlich ist, weil man mit gängigen Tools auf die DB zugreifen kann.

 

[schmeckzilla]

Eigentlich will ich den Luxus einer "normalen" SQL-Datenbank ohne das auf dem Rechner ein Datenbankserver wie mysql o. postgresql installiert ist. Auf die Datenbank wird nur durch meine noch zu schreibende Anwendung zugegriffen. In der Anwendung selbst will ich mich aber nicht auf das Parsen und SQL-Kompatibilität kümmern, sondern einfach per JDBC auf die in der Datei gespeicherten Daten zugreifen und auch ändern können.

Auf SQLite bin ich gekommen, da ich darüber etwas im Zusammenhang mit Perl gehört habe. Mittlerweile habe ich mir derby etwas genauer angeschaut. Derby scheint das von mir oben beschriebene zu erfüllen, richtig?

Danke für den Tipp zu Derby. Habe mir auch gleich das Derby-Plugin für Eclipse installiert.

Da u.a. SQlite, HSQLDB und Derby diesen Zweck erfüllen, gibt es irgendwelche logischen Gründe die für oder gegen eine DB sprechen. (z.B.: X wird nicht mehr entwickelt, oder y erfüllt den ANSI SQL Standard, ...)

Zur Zeit würde ich mich auf Grund meines Bauchgefühles und da ich Apache-Projekte mag ( ) mich für Derby entscheiden.

 

[AlArenal]

Eigentlich will ich den Luxus einer "normalen" SQL-Datenbank ohne das auf dem Rechner ein Datenbankserver wie mysql o. postgresql installiert ist. Auf die Datenbank wird nur durch meine noch zu schreibende Anwendung zugegriffen.

Iss schon klar. So macht es z.B. BlogBridge (mit HSQLDB).

In der Anwendung selbst will ich mich aber nicht auf das Parsen und SQL-Kompatibilität kümmern, sondern einfach per JDBC auf die in der Datei gespeicherten Daten zugreifen und auch ändern können.

JDBC ist lediglich ein Vehikel, SQL brauchst du trotzdem und damit hast du automatisch mit dem SQL-Dialekt der Ziel-Datenbank zu tun. Je nachdem wie komplex und spezifisch deine Abfragen sind und ob du die DB um FUnktionen erweiterst, sind die Abfragen dann am Ende mehr oder weniger kompatibel zu anderen RDBMS. Stellt sich die Frage, ob Kompatibilöität zu anderen DBs überhaupt eine Rolle spielt.

Auf SQLite bin ich gekommen, da ich darüber etwas im Zusammenhang mit Perl gehört habe.

Dass SQLlite auf C basiert und damit eine native Anwendung ist, ist dir aber schon klar?

Mittlerweile habe ich mir derby etwas genauer angeschaut. Derby scheint das von mir oben beschriebene zu erfüllen, richtig?

So unspezifisch wie deine Anforderungen waren, erfüllen folgende DBs wohla lle deine Forderungen:

* Cloudscape/Derby
* Fositex
* HSQLDB
* InstantDB
* JDataStore
* McKoi SQL Database
* SimpleText Database
* SmallSQL Database

Da u.a. SQlite, HSQLDB und Derby diesen Zweck erfüllen, gibt es irgendwelche logischen Gründe die für oder gegen eine DB sprechen. (z.B.: X wird nicht mehr entwickelt, oder y erfüllt den ANSI SQL Standard, ...)

Klar gibt es Gründe für und gegen den Einsatz von RDBMS, darum gibt es wohl Anwendungen die welche benutzen und welche die es nicht tun. Ich weiß ja nicht was genau du alles in deine Anwendung reinpacken willst. Auf den ersten Blick würde ich sagen, dass man nicht zwingend eine DB benötigt, aber es vereinfacht später womöglich die Erweiterung, weil man schnell mal ne Volltextsuche zusammengekloppt hat, die man anderweitig selbst stricken oder auf Lucene aufbauen müsste...

Zur Zeit würde ich mich auf Grund meines Bauchgefühles und da ich Apache-Projekte mag ( ) mich für Derby entscheiden.

Ich würde eher mal die Alternativen abklopfen und mal mit allen rumspielen. Sonst schießt man schnell mal mit Kanonen auf Spatzen. Derby ist im Vergleich der o.g. Kandidaten schon ein "Brocken". Vermutlich ist SmallSQL für deine Belange schon mehr als ausreichend und dabei wohl der schlankeste Vertreter.