Bestes Datenbanksystem zum "embedden"

[Guybrush Threepwood]

Es gibt so viele verschiedene Datenbaksysteme. Welche ist die beste "embeddable" Datenbank, also welche sollte man wählen, wenn man einer Stand-Alone-Applikation eine lokale Datenhaltung in einer Datenbank mitgegeben möchte: Apache Derby, SQLite, Oracle Berkeley DB Java Editio, oder was gibt es sonst noch? Was sind Eurer Meinung nach die jeweiligen Vor- und Nachteile? Was verwendet Ihr?

 

[maki]

HSQL & H2 bitte nicht vergessen

 

[ice-breaker]

Kommt das nicht auf die Anforderungen an?
Datenmenge, Funktionalitäten usw.

 

[Guybrush Threepwood]

Kommt das nicht auf die Anforderungen an?
Datenmenge, Funktionalitäten usw.

Stimmt schon. Ich dachte so an den Regelfall, z. B. Verwalten von Personeninformationen wie Personalverwaltung, Kundendaten, Patientenakten oder Inventarlisten etc..

 

[frapo]

Meine Stimme würde an H2 gehen.

 

[L-ectron-X]

Umfrage entsprechend erweitert.

 

[Guybrush Threepwood]

Interessant! Wieso H2?

 

[maki]

Interessant! Wieso H2?

Weil es dir doch um embedded DBs geht, oder?

 

[Guybrush Threepwood]

Weil es dir doch um embedded DBs geht, oder?

Ja, klar! Aber wieso ist H2 besser als z. B. Derby?

 

[The_S]

Hab auch mal für H2 gestimmt .

 

[L-ectron-X]

Ja, klar! Aber wieso ist H2 besser als z. B. Derby?

Sie ist wesentlich schneller.

 

[Guybrush Threepwood]

Sie ist wesentlich schneller.

Vielen Dank für die Info. Ich habe mir gerade die Performance-Vergleiche auf der H2-Seite angesehen, und die sprechen wirklich eine deutliche Sprache.
Wie ist es eigentlich mit der Sicherheit? Wie groß ist die Gefahr, dass eine Datenbank beschädigt wird, wenn das Programm während des Zugriffs abgeschossen wird? Sind da die Datenbanken gleichermaßen verlässlich?

 

[Gast2]

Wie ist es eigentlich mit der Sicherheit? Wie groß ist die Gefahr, dass eine Datenbank beschädigt wird, wenn das Programm während des Zugriffs abgeschossen wird? Sind da die Datenbanken gleichermaßen verlässlich?

welches Programm - Deines oder die Datenbank selber ... im ersteren Fall sollte nichts passieren ... im zweiten Fall eigentlich auch nicht ... in beiden Fällen sollte das Transaktions-Konzept eine fehlerhaften Zustand der DB verhindern

 

[frapo]

Interessant! Wieso H2?

Für mich geht es gar nicht unbedingt darum das H2 'besser' als Derby ist oder nicht.

Ich habe mich letztes Jahr für H2 entschieden, weil mir das ganze Paket gefällt: Doku, Tools, recht stete Arbeit(und damit Verbesserung) an H2.

Gruß
frapo

 

[ice-breaker]

welches Programm - Deines oder die Datenbank selber ... im ersteren Fall sollte nichts passieren ... im zweiten Fall eigentlich auch nicht ... in beiden Fällen sollte das Transaktions-Konzept eine fehlerhaften Zustand der DB verhindern

ja das ist so eine Sache, prinzipiell sollte es gewährleistet sein.
Das Betriebssystem und Festplatten-Caches können da nochmal einen Strich durch die Rechnungen machen, wenn diese melden es wurde alles geschrieben, dies wird aber erst im Hintergrund gemacht (Write-Back-Cache).
Bricht dieses Schreiben dann auf Grund eines Power-Failures ab, ist auch die Datenbank in einem inkonsistenten Zustand, da das Transaktionskonzept von der Korrektheit der Rückgabe der Schreiboperation ausgeht.

Das ist auch der Grund warum bei InnoDB-Datenbanken (MySQL) der Festplatten-Cache deaktiviert werden sollte und man lieber auf den Write-Back-Cache von Raid-Controllern mit extra Batteriesicherung setzen sollte.

Anmerkung: Dies ist natürlich ein Worst-Case sollte aber noch Erwähnung finden, dass auch die Systeme die die Durability (ACID) gewährleisten sollen, nicht 100% perfekt sind.

 

[Guybrush Threepwood]

Nach dieser Umfrage bin ich auch auf H2 umgestiegen und bislang sehr zufrieden.

H2 macht wirklich einen sehr guten Eindruck. Im Detail unterscheidet sich die SQL-Syntax wieder ein bisschen von Derby und MySQL, aber es gibt sogar Kompatibilitätsmodi zu diesen Datenbanken. Praktisch ist die Backup-Funktion, mit der sich die gesamte Datenbank als ZIP-Datei sichern lässt. Die Startzeit ist (gefühlt) kürzer als bei Derby, wo man eine kurze Verzögerung merkt. Die Datentypen entsprechen - soweit ich das beurteilen kann - Java etwas besser als Derby und MySQL- auch das ein Vorteil. Die Dateigrößen und der Speicherverbrauch sind geringer und die Geschwindigkeit deutlich höher als bei Derby. Die Entwicklergemeinde ist sehr rege und wesentlich aktiver als bei Derby. Ich habe noch keine Erfahrungen im Produktiveinsatz. Immerhin existiert das Projekt bereits 5 Jahre und knüpft an die HSSQLDB an. Von daher ist zu erwarten, dass die Sicherheit hoch ist.

Ich glaube, sie ist sehr gut verwendbar ich bin bisher recht zufrieden.

 

[robertpic71]

Die Entwicklergemeinde ist sehr rege und wesentlich aktiver als bei Derby.

Das ist vielleicht der einzige Negativpunkt bei H2: Es gibt nur einen Hauptentwickler (Thomas Müller) und nur punktuelle Verbesserungen aus der Community. Trotzdem gibt es bei H2 am meisten Bewegung.

Ich habe noch keine Erfahrungen im Produktiveinsatz.

Ich hatte bei meinen Projekten noch keine Probleme. Weder bei meinem Katalog (ca. 400MB Content in der DB) noch bei meinem Planungsprogramm (12 Dateien, mit Spring/JPA/Hibernate) - noch bei meinen Inhouseprojekten.

Ich arbeite normalerweise mit DB2, Oracle und MSSQL. Für kleiner Projekte ziehe jederzeit H2 vor.

/Robert

 

[mvitz]

Hallo robertpic71.

Ich habe zur Zeit folgendes Problem mit der Kombination Spring/JPA/H2: http://www.java-forum.org/datenbankprogrammierung/92153-spring-jpa-hibernate-h2.html evtl. kannst du da in diesem Thread etwas zu sagen, oder mir evtl. einmal beispielhaft deine Konfigurationen posten.

Danke schon mal im voraus.

 

[kama]

Hi,

wie wäre noch mit db4o ?

Gruß
Karl Heinz Marbaise

 

[guni]

Hallo,

interessantes Thema, das ihr da ansprecht.
Hab mich auch mal damit befasst, den Gedanken aber irgendwie wieder verworfen ...

ich sehe, dass H2 hier viele positive Stimmen kriegt. Ein Grund, sich mal wieder damit auseinanderzusetzen.

Dann gibt es ja auch noch - ich glaub es wurde oben sogar schon erwähnt - sqllite; das ist auch so eine embedded db, oder?! Was haltet ihr davon?

und noch was: hat nicht mozilla auch irgend sowas im netz? firebird heißt das ding glaub ich ...

was mich auch noch interessieren würde: gibt es eigentlich auch hierarchische embedded db's und welche erfahrungen habt ihr da?! ldap wäre in manchen Situationen oft mal viel schöner als irgendwas relationales ;-)

mfg, guni

 

[mvitz]

Hi,

wie wäre noch mit db4o ?

Gruß
Karl Heinz Marbaise

Habe zwar in dem Sinne noch keine "produktive" Erfahrung mit db4o gemacht, aber unser Java Professor mag d4bo sehr und daraus resultierend, habe ich mit db4o schon mehrere kleine Studienprojekte erledigt.
Meiner Meinung nach, ist db4o für solche kleinere Projekte (insbesondere im embedded Bereich) sehr gut einzusetzen und erspart einem SQL komplett. Auch die unterschiedlichen Methoden der Abfrage sind sehr gut.

Edit:
Zu SQLite habe ich zwar bisher keine Java Erfahrung, sondern lediglich aus einem Django Projekt (Rails für Python) und muss sagen, da lief das ganze einwandfrei und war wesentlich einfacher, als eben mal ne MySQL DB aufzusetzen.

 

[Guybrush Threepwood]

db4o sieht auch sehr spannend aus und wäre auch sehr komfortabel. Allerdings ist es GPL und die commercial license kostet 1200$ für einen einzelnen Developer, und da ist noch nicht einmal redistribution dabei! Das ist echt happig. Umgerechnet in Arbeitszeit kann man dafür tonnenweise SQL coden, und ist kann dann auch relativ einfach zwischen unterschiedlichen Datenbank-Systemen umschalten. Außerdem gibt es dann ja auch noch xml, sodass db4o dadurch komplett unattraktiv wird.

 

[DStrohma]

Mich wundert es hier wirklich dass keiner ein Wort zu SQLite verliert... Ich bin gerade dabei mir zu überlegen wo ich meine Daten lokal speichere und wollte eigentlich irgend einen SQLite treiber nehmen aber grad bin ich mir nicht mehr sicher

Überlege H2 auszuprobieren. Gibt es etwas das gegen SQLite spricht?

 

[maki]

db4o sieht auch sehr spannend aus und wäre auch sehr komfortabel. Allerdings ist es GPL und die commercial license kostet 1200$ für einen einzelnen Developer, und da ist noch nicht einmal redistribution dabei! Das ist echt happig. Umgerechnet in Arbeitszeit kann man dafür tonnenweise SQL coden, und ist kann dann auch relativ einfach zwischen unterschiedlichen Datenbank-Systemen umschalten. Außerdem gibt es dann ja auch noch xml, sodass db4o dadurch komplett unattraktiv wird.

1200$ sind zurzeit ca. 1000,- €, umgerechnet in Arbeitszeit sind das zwischen 15 und 9,5 Stunden.
Das ist weder happig, noch kann man da tonnenweise sinnvollen SQL Code ausspucken.

Kann das Argument gegen db4o nicht nachvollziehen.

 

[DStrohma]

1200$ sind zurzeit ca. 1000,- €, umgerechnet in Arbeitszeit sind das zwischen 15 und 9,5 Stunden.
Das ist weder happig, noch kann man da tonnenweise sinnvollen SQL Code ausspucken.

Kann das Argument gegen db4o nicht nachvollziehen.

:applaus:
Dickes Argument!

 

[Empire Phoenix]

Komerziell oder für eine firma evtl. sinnvoll, aber private tue ich mir da lieber tausende handgeschreibene Querys an.

 

[Guybrush Threepwood]

Per Developer-Lizenzen sind für mich völlig ok, und ich bin auch gerne bereit 1000 Euro hinzublättern, wenn das eine sinnvolle Erweiterung meiner Programme darstellt. Das Problem ist in der Regel das Deployment. Wenn hier Extrakosten anfallen, dann wird das schnell unattraktiv und v. a. die Abrechnungen sind problematisch. Ich entwickle i. d. R. im Auftrag von Verlagen, die dann an Endkunden ausliefern. Die Verlage sind zu solchen Dingen nicht bereit und dann ist das meist von vorneherein gestorben. Schade für die Entwickler der Bibliotheken, weil die verdienen dann auch nichts.

P.S.: Danke für die Tipps zu H2. Das ist mittlerweile meine Standard-Bibliothek und ich bin unheimlich zufrieden damit.

 

[maki]

Per Developer-Lizenzen sind für mich völlig ok, und ich bin auch gerne bereit 1000 Euro hinzublättern, wenn das eine sinnvolle Erweiterung meiner Programme darstellt. Das Problem ist in der Regel das Deployment. Wenn hier Extrakosten anfallen, dann wird das schnell unattraktiv und v. a. die Abrechnungen sind problematisch. Ich entwickle i. d. R. im Auftrag von Verlagen, die dann an Endkunden ausliefern. Die Verlage sind zu solchen Dingen nicht bereit und dann ist das meist von vorneherein gestorben. Schade für die Entwickler der Bibliotheken, weil die verdienen dann auch nichts.

P.S.: Danke für die Tipps zu H2. Das ist mittlerweile meine Standard-Bibliothek und ich bin unheimlich zufrieden damit.

Meine Kunden im Automobilbereich & Flugzeugbau rechnen mit 105,- € pro Stunde für interne, festangestellte Mitarbeiter, externe die für 65,- € die Stunde arbeiten sind da ein Schnäppchen
Trotzdem versucht der Einkauf immer die Stundensätze zu drücken wo nur möglich...

Komerziell oder für eine firma evtl. sinnvoll, aber private tue ich mir da lieber tausende handgeschreibene Querys an.

Dann tue dir lieber die GPL Lizenz an, oder nimm etwas anderes freies

 

[Tomate_Salat]

H2. Warum? Liebe auf den ersten Blick

Mir gefällt das ganze paket.

 

[Gelöschtes Mitglied 5909]

h2 dito