Peristenz: Besagt lediglich das etwas außerhalb des Programlebenszyklus erhalten bleibt. Hat also nichts mit Branches & Co an sich zu tun.
JDO: Momentan wohl der neue Standard der Persistierung. Vielleicht ein Standard mit dem Potential, irgendwann mal JDBC ersetzen zu können. Im Grunde genommen die Weiterentwicklung von ODMG, nur das JDO im Gegensatz zu ODMG von der Wirtschaft akzeptiert wird.
Warum JDO anstelle von SQL basierten Datenbanken? Simpel: Weil der Programmierer nicht in SQL / Tupeln denken will. Der Programmierer will ausschließlich mit Objekten arbeiten und gerade hierfür ist JDO gebaut worden. Es ist zudem so ausgelegt worden das man dahinter sowohl relationale als auch objektorientierte Datenbanken pappen kann.
Die Versant DB ist im übrigen eine solche Objektdatenbank. Im Grunde genommen sind OO DBs den relationalen Brüdern überlegen, aber dennoch konnten sie bis heute keinen Fuß fassen. Ausnahmen sind vielleicht einige wenige Nischen wie z.b. im embedded Bereich, wo Datenbanken wie db4o.de durchaus einen guten Weg darstellen. Auch Versant bedient im Grunde genommen nur eine Nische, da die meisten Firmen an Oracle & Co gebunden sind.
Welchen Vorteil bringt es dir als Programmierer auf JDO zu setzen? Simpel: Du kannst dahinter jederzeit beliebige Datenbanken hängen und somit effektiv diese in der Performance vergleichen. Zudem ist es in der Regel so, das die automatische SQL Generierung des JDO Mappers gut genug ist. Sicher wenn man ein einzelnes Statement handoptimiert wird der Mapper langsamer sein, aber in der Regel produziert dieser schnelleres SQL als man dies händisch ausformulieren könnte.
Zudem sind die meisten JDO Mappern einem direkten SQL Zugriff überlegen, da sie mehrere Level an Caches vorweisen können. Bis hin zu VM übergreifenden Distributed Caches ist alles denkbar.
Zur Frage des Urpsrungsposters: Kauf dir ein Datenbankenbuch das sich dem Them Performance widmet. Es wäre hier und jetzt ein wenig vermessen dir die Basics beibringen zu wollen.
Warum kann eine DB langsamer sein als sie sein könnte? Sind Indexe effizient gesetzt? Normalisierungsfehler? Muß man eventuell an einer bestimmten Stelle denormalisieren um der Performance genügen zu können? Sollte man vielleicht den Index auf eine andere physische Platte legen? Sollte man vielleicht anstelle des normalen Filesystems dem RDBMS ein Raw Device zuweisen, wodurch er sich den Umweg übers Filesystem ersparen kann? Wäre vielleicht ein Raid die Lösung zur Problembehebung?
Oder sind wir gerade in die falsche Richtung gegangen? Ist vielleicht einfach nur deine Applikation der Flaschenengpass? Vielleicht irrst du dich ja und die DB stellt gar nicht den Engpass dar. Ja selbst dies wäre möglich.
MySQL ist im übrigen nicht wirklich eine schnelle DB. Ja sicher bei den Hobbyentwicklern ist es die schnellste / bestigste DB überhaupt, aber mal ehrlich, deren Anforderungen spiegeln nicht wirklich eine reale Applikation wieder. Sobald viele Relationen bestehen, multiple Threads transaktionssicherheit wollen und einfach die Anforderungen nach oben geschraubt werden. Ja ab da sind in der Regel ganz andere Datenbanken "schnell". Sogar die angeblich langsamere PostgreSQL kann hier recht schnell als Sieger hervorgehen.
Hol dir ein Buch das all diese Themen abdeckt und lern dich dort ein wenig ein. Eventuell lohnt es sich auch einen Consultant hinzuzuziehen der exakt nach deinen Randbedingungen Lösungen vorschlägt. (Bedenke, für den Preis einer VersantDB / Oracle kannst du schon einiges an Hardware upgraden, was eventuell also eine effizientere Lösung darstellt).
Die meisten relevanten Bedingungen sind eben Applikationsspezifisch und somit können wir eigentlich nur generisch ins Blaue raten.
Im übrigen finde ich deinen Beitrag witzig.
Ich möchte mich aber nicht durch die Verwendung von Nicht-Standardbefehlen auf FastObjects festlegen, sondern suche mehr eine Open Source Standart Objekt Datenbank, wie sie jetzt wohl vom Jakarta Projekt in der Entwicklung ist.
Cybis Interpretierung: Ich möchte nicht eine teure FastObjects sondern eine gratis Jakarta. Ich möchte nicht einen bezahlten Consultant bemühen, sondern hier gratis Lösungen erhalten;o)
Warum denke ich so? JDO und somit Versant ist eher Standard als die meisten Implementierungen auf Jakarta. Jakarta Projekte hingegen sind frei / gratis aber nunmal in der Regel nicht Standard, denn Projekte wie Torque sind weit weg vom Standard. OJB wird JDO irgendwann mal wirklich supporten (angestrebt bei 2.0 wenn ich mich nicht irre). Etc. etc.
cybi
