PostgreSQL vs Firebird vs Derby

[Deadalus]

Hallo,

Es geht um ein Projekt im JEE Umfeld. DB Zugriff wird über JPA laufen evtl. werden später mehere DB's in einer XA Ressource benutzt.

Da MySQL aus lizenrechtlichen Gründen für mich nicht in Frage kommt brauche ich eine neue Datenbank. Allerdings bräuchte ich eure Hilfe bei der Entscheidungsfindung.

Was ich bisher so an Infos gesammelt reicht mit bisher noch nich.

Alle 3 Datenbanken sollen eine gute Geschwindigkeit haben und man hört allgmein viele positive Dinge über alle 3. Bisher hab ich nur bei der Dokumentation größere Unterschiede vernommen. Hier soll PostgreSQL führend sein, die Firebird Doku "ok" sein und Derby noch deutlich zu wünschen übrig lassen.

Die Lizenzen sind sich relativ ähnlich wenn es darum geht die DB in einem kommerziellen Projekt zu benutzen. PostgreSQL (BSD) Firebird(IDPL) und Derby(Apache License 2.0)

An Derby finde ich persönlich sympatisch, dass Derby komplett in Java geschrieben wurde. So mann eine bestehende Datenbank einfach auf ein beliebiges OS kopieren ohne Backups und Imports zu machen.

So jetzt bräuchte ich eure Meinungen. Hat jemand schon Efahrungen mit einer oder mehreren der Datenbanken gemacht und möchte diese mit mir teilen? Ich sag schon mal danke im Vorraus.

 

[maki]

Du willst einen Tipp für eine DB ohne irgendwelche Anforderungen zu stellen ausser

Alle 3 Datenbanken sollen eine gute Geschwindigkeit haben

?

Kannst alle 3 nehmen, ich empfehle Derby (weil es autom. "installiert" werden kann zB. von Ant oder Maven2, gut für autom. Tests), läuft sehr gut mit EclipseLink und ganz gut mit DBUnit.

 

[Deadalus]

Das mit der Geschwindigkeit war keine Anforderung meinerseits, sondern eine Vermutung auf dem was ich bisher gehört (gelesen) habe.

Mein "Problem" ist viel eher, das alle 3 Datenbanken meine Anforderungen erfüllen und einfach Anregungen brauche warum ich eine den anderen vorziehen sollte.

 

[musiKk]

Wenn alle die Anforderungen erfüllen, kannst Du ja würfeln. Ich würde nach dem bisherigen Umfeld gehen und auch, was die Leute in meiner Umgebung am besten können... so kam ich jedenfalls zu Postgres.
Wenn Du nicht viele herstellerspezifischen Eigenschaften der DBs (Stichwort SQL-Standard, Postgres vermerkt in der Doku immer, inwieweit sie dem Standard entsprechen oder nicht) nutzt, sollte ein etwaiger Wechsel ohnehin nur wenige Probleme bereiten.

 

[JanHH]

Ähm.. also ist Derby nicht lediglich eine kleine "embedded" java-DB, so wie HSQL, daher nur für recht spezielle Zwecke produktiv nutzbar, sonst eher zum Testen? Und PostgresQL eine "grosse" Datenbank wie MySQL, und kann durchaus mit kommerziellen Produkten wie teuren Oracle-Datenbanken konkurrieren? Irgendwie werden da doch Äpfel mit Birnen verglichen, wenn ich mich nicht irre.

Wenns ein grosses Projekt wird, kommt an sich nur Postgres in Frage, bei kleinen Sachen ist es im Grunde ziemlich egal.. und da Du eh mit JPA arbeiten willst, kannst Du die DB sowieso jederzeit austauschen.

 

[maki]

Derby läuft auch als Server, oder als embedded.
Testen geht damit gut, ist aber langsamer als HSQL, produktiv läuft sich auch gut, würde Derby auch in dieselbe Kategorie wie MySQL einordnen, ist bei mir aber nicht die Kategorie in der DB2 oder Oracle spielen

und da Du eh mit JPA arbeiten willst, kannst Du die DB sowieso jederzeit austauschen.

Naja, Oracle erzeugt Ids per Sequence, das können nicht so viele andere DBs

 

[JanHH]

Also in meiner Weltvorstellung gibt es grob drei kategorien von (relationalen) Datenbanken:

- kleine, in java geschrieben, embedded nutzbare, die nur für kleine Anwendungen, zum Testen oder rumspielen geeignet sind, dafür im embedded mode teilweise sehr schnell (HSQLDB, Derby, JavaDB, H2)
- "grosse freie" Datenbanken, die für den richtigen Produktivbetrieb geeignet sind und mit grossen Datenmengen klarkommen (MySQL, PostgreSQL)
- grosse Kommerzielle Datenbanken (oracle)

wobei die beiden letzten Kategorien ein bisschen ineinander verschwimmen. Ich bin aber auch Neuling auf dem Gebiet, aber das ist so das Bild, was man bekommt, finde ich.

Wie die IDs nun generiert werden, ist aber doch an sich egal, wenn man alles sauber per JPA macht und schön kapselt..

 

[maki]

- kleine, in java geschrieben, embedded nutzbare, die nur für kleine Anwendungen, zum Testen oder rumspielen geeignet sind, dafür im embedded mode teilweise sehr schnell (HSQLDB, Derby, JavaDB, H2)
- "grosse freie" Datenbanken, die für den richtigen Produktivbetrieb geeignet sind und mit grossen Datenmengen klarkommen (MySQL, PostgreSQL)

Derby == JavaDB
Derby ist aber nicht so schnell wie H2 oder HSQL, denn Derby ist keine richtige In-Memory DB, wie gesagt, Derby gehört für mich in dieselbe Kategorie wie MySQL & PostgreSQL.

Wie die IDs nun generiert werden, ist aber doch an sich egal, wenn man alles sauber per JPA macht und schön kapselt..

JPA Hausmittel reichen dafür nicht aus:

@Id
@GeneratedValue(strategy=GenerationType.SEQUENCE)

Müsste man wieder ändern wenn man statt Oracle eine andere DB einsetzen will.
Datanucleus (ehem. JPOX) kann damit umgehen, da dort explizit noch ein Mappingfile unterstützt wird, da wird das nur mit @Id annotiert und erst im Mappingfile (orm.xml) festgelegt wie die ID erzeugt wird, da braucht man den Javaquellcode im nachhinein nicht zu ändern, andes als bei nacktem JPA.
Man merkt schon immer wieder den qualitativen Unterschied zwischen JPA und JDO imho.

 

[musiKk]

Bei den IDs kocht irgendwie jede Datenbank ihr eigenes Süppchen. Postgres benutzt z. B. auch Sequenzen für automatisch generierte IDs und dort muss die Annotation [c]@GeneratedValue(strategy=GenerationType.IDENTITY)[/c] lauten. In dem Fall wird es aber wohl daran liegen, dass Oracle einen Trigger benötigt (laut diversen Google-Fünden), während Postgres die Möglichkeit hat, das Resultat einer Funktion als Defaultwert zu verwenden (in diesem Fall die Funktion [c]nextval()[/c] angewandt auf die Sequenz).

Aber wie auch immer. Eine Datenbank auszutauschen, wird in den meisten Fällen nicht reibungslos gehen. Selbst JPA-Provider lassen sich nicht immer völlig transparent austauschen. Ich habe eine Weile mit EclipseLink und Hibernate experimentiert und da gibt es doch ein paar Unterschiede. Siehe auch Leaky Abstraction.

da wird das nur mit @Id annotiert und erst im Mappingfile (orm.xml) festgelegt wie die ID erzeugt wird, da braucht man den Javaquellcode im nachhinein nicht zu ändern, andes als bei nacktem JPA.

Was meinst Du mit nacktem JPA? Eine orm.xml kann man ja immer definieren und vorhandene Annotations überschreiben. Das ist ja nicht speziell für Datanucleus, sondern steht in der JPA-Spezifikation.

 

[maki]

Was meinst Du mit nacktem JPA? Eine orm.xml kann man ja immer definieren und vorhandene Annotations überschreiben. Das ist ja nicht speziell für Datanucleus, sondern steht in der JPA-Spezifikation.

Ooops.. hast recht

 

[homer65]

Hallo,
Alle 3 Datenbanken sollen eine gute Geschwindigkeit haben und man hört allgmein viele positive Dinge über alle 3. Bisher hab ich nur bei der Dokumentation größere Unterschiede vernommen. Hier soll PostgreSQL führend sein, die Firebird Doku "ok" sein und Derby noch deutlich zu wünschen übrig lassen.

Ich protestiere, die Dokumentation von Derby ist ok. Sie wird direkt mit der Software im Unterverzeichnis docs geliefert.

 

[Deadalus]

Ich protestiere, die Dokumentation von Derby ist ok. Sie wird direkt mit der Software im Unterverzeichnis docs geliefert.

Ich habe ja auch nur wiedergegeben, was ich gehört hatte. Allerdings hoffe ich mal, dass du noch andere Gründe hast warum die Derby Doku ok ist außer, dass sie direkt mit der DB ausgeliefert wird.

 

[homer65]

Hab auch schon mal reingekuckt und es war für meine Zwecke ok.