# db4o und Performance



## Ralf Ueberfuhr (28. Sep 2005)

Hallo,

Ich überlege zum ersten Mal, eine Objektdatenbank wie db4o zu verwenden. Meine Frage dazu: Wie stehts zur Zeit mit der Performance von Objektdatenbanken? Sind sie ähnlich flink wie MySQL?


----------



## Bleiglanz (28. Sep 2005)

was heisst "zur Zeit"?

die Objektdatenbanken können [auf bestimmten Gebieten] NIE so schnell sein wie eine relationale Datenbank

vor allem bei SELECT(SUM(...)...) oder SELECT(MAX(..)...) beissts bei denen IMHO aus 

AFAIK wird der Einsatz empfohlen, wenn es viele Objekte mit SEHR vielen Beziehungen gibt in denen man navigieren muss, dann wird nämlich SQL extrem unhandlich wegen der zahlreichen Fremdschlüssel

schätze aber mal dass es für kleinere DBs schon eine Alternative ist, mach halt mal ein paar Tests?


----------



## Ralf Ueberfuhr (28. Sep 2005)

Ok, muss halt nur wissen, ob sich die Tests überhaupt erstmal lohnen.

Ich probier's aus. Danke erstmal.


----------



## AlArenal (28. Sep 2005)

Ich glaube die Frage ist schon "falsch" 
Du kannst, um bei den Beispielen zu bleiben, db40 nicht 1:1 mit einer relationalen DB vergleichen, denn bei letzerer bekommst du ja zunächst nur Daten und musst diese erst wieder in deine Objekte reinbekommen (und aus diesen wieder in die DB). Wenn du dann noch Datenhaltung und Logik auch physisch trennst (DB und Anwendung auf unterschiedlichen Maschinen), wirds mit der Vergleichbarkeit noch komplizierter, weil du dann in der Arbeit mit db4o auf RMI o.ä. zurückgreifen musst. 

Ist immer Äpfel mit Birnen zu vergleichen. Ist zwar beides Obst, aber das isses dann auch mit Gemeinsamkeiten..

Wenn ich mich recht entsinne ist db4o auch kommerziell und kostet pro eingesetzter Anwendung Lizenzgebühren. Letztens stolperte ich noch über JoSQL, was auch sehr nett zu sein scheint um SQL-Abfragen über Objekte laufen zu lassen.

http://josql.sourceforge.net/index.html

Grundsätzlich entscheidet sich glaube ich niemand rein aus Performance-Gründen für oder gegen eine relationale DB contra db4o, da das Anwendungsdesign in beiden Fällen doch stark unterschiedlich sein dürfte. Und ob eine vergleichbare Abfrage inkl. Instanz-Erzeugung  für große Datenmengen nun bei der einen oder anderen Lösung Laufzeutunterschiede im einstelligen Bereich hat, ist in der Praxis in den meisten Fällen nicht relevant.

Wenn ich sehe wie schlecht manche SQL-Datenbanken aufbauen, den Server konfigurieren und die Abfragen gestalten, könnte man oft auch gleich mit flat files arbeiten 

P.S.:
http://www.db4o.com/about/productinformation/benchmarks/


----------



## Bleiglanz (28. Sep 2005)

masseur81 hat gesagt.:
			
		

> Ok, muss halt nur wissen, ob sich die Tests überhaupt erstmal lohnen.
> Ich probier's aus. Danke erstmal.



es kommt eben darauf an was man machen will: zum Programmieren in Java ist so eine OO-Datenbank wahrscheinlich komfortabler als etwa das Gespann Hibernate+SQL-DB

Wenn

*es um überschaubare Datenmengen geht 

*und keine komplexen statistischen Abfragen a la "alle Kunden, die im letzten Jahr mehr als 1000€ Umsatz hatten" 

*und der Einsatz einer solchen Dingens "philosophisch" OK ist (Support, Team-Skills, usw.)

Oder wenn

*wahnsinnig komplexe Beziehungen zwischen den Entitäten bestehen

dann würd ich das auch gerne mal machen


----------



## Ralf Ueberfuhr (28. Sep 2005)

In meinem Falle möchte ich ein erweiterbares Programm mit Datenbankanbindung umsetzen. Erweiterbar heißt, dass man es PlugIns und damit auch um neue Datenstrukturen erweitern kann, die dann auch in die DB sollen. Mit SQL muss ich mir was einfallen lassen, SQL2Java z.B.

Danke erstmal für die guten Antworten.


----------

