Java Datenbankanwendung

bei java wäre

http://hsqldb.org/


naheliegend ?!

http://www.torsten-horn.de/techdocs/java-hibernate.htm

Hibernate ist wohl für den Anwendungsbereich optimal

Holger S. schrieb:
> http://www.torsten-horn.de/techdocs/java-hibernate.htm
>
> Hibernate ist wohl für den Anwendungsbereich optimal

Warum gleich mit einer Saturn 5 auf ein Spielzeugauto schießen?

JDBC ist einfach zu programmieren und funktioniert einwandfrei, sogar 
völlig problemlos und transparent mit unterschiedlichen Datenbanken, 
solange man keine exotischen Dinge macht.
Mit hibernate oder JPA brauchst du erst mal Wochen Einarbeitungszeit, 
und wenn dann mal etwas mehr von der Datenbankschnittstelle gefordert 
wird, (Performance / Mutlitasking) dann hast du Fehler wo du tagelang 
wie der Ochs vorm Berg stehen kannst.
Wir haben hier mehrere Versuche damit gemacht und auch produktiv, die 
Leute die es gemacht haben machen das nächse Mal ihre DB-Objekte 'von 
Hand' mit JDBC wenn sie dürfen.

@Sebastion: Schau dir "Java ist auch eine Insel" an, dort ist der JDBC 
Zugriff beschrieben, du brauchst nur einen passenden JDBC Treiber und 
eine Datenbank deines Vertrauens. Wenn die oben genannten Datenbanken 
nicht passen, es gibt auch MS-SQl Server Express kostenlos. Funktioniert 
einwandfrei. Und dank JDBC brauchst du egal welche DB in der Software 
nichts ändern.

>eine java-db nehmen deren code
>mit dem eigentlichen programm zusammengepackt werden kann.

diesen Vorschlag gab es hier eh schon mehrfach (HSQLDB)
(was ist an Derby besser ??)

>für ein paar dämliche schülerdatensätze

die Anzahl ist aber nicht das einzige Kriterium, sonder z.B.  auch ob 
man von mehreren Rechner zugleich zugreifen will/muss

c. m. schrieb:
> korrekt. möglicherweise solls auch ein ha cluster mit
> indexpartitionierung und transaktionsicherem online-backup werden... wer
> weiß.

Und das kann der Anwendung erstmal schnulleregal sein, weil die nur eine 
Standardschnittstelle benutzt. Was da an Datenbank dahintersteht sollte 
vollständig transparent und egal sein, und im Falle von JDBC kann man 
das durchaus so programmieren.

c. m. schrieb:
> Robert L. schrieb:
>>>eine java-db nehmen deren code
>>>mit dem eigentlichen programm zusammengepackt werden kann.
>>
>> diesen Vorschlag gab es hier eh schon mehrfach (HSQLDB)
>> (was ist an Derby besser ??)
>
> keine ahnung. (würde ich aber auch gerne wissen ohne mich jetzt konkret
> einarbeiten zu müssen - also wenn jemand 2-3 sätze darüber schreiben
> könnte würde ich mich freuen.)

Es sind zwei verschiedene Projekte mit verschieden Zielen. Ist schon 
etwas her seit ich mich das letzte mal damit befasst habe, aber 
grundsätzlich sind folgendes die Hauptunterschiede:

HSQLDB ist extrem klein (das JAR file), jedoch ist es eine "In Memory" 
Datenbank, die beim Speichern einfach SQL Statements speichert und beim 
starten diese wieder lädt.

Derby ist grösser, verwendet ein Binary Format und ist viel performanter 
(bezüglich laden / speichern).
Derby kann auch als Standalone Sever laufen, soweit ich weiss geht das 
bei HSQLDB nicht.

Für ein kleines Projekt (max. 10 Tabelle mit max. 1000 Datensätzen) 
würde ich HSQLDB vorziehen, der grösste Vorteil sehe ich darin das man 
die Datenbank einfach kurz im Texteditor öffnen kann, ohne Admintool 
etc.

mfg Andreas

@ andras

wenn du mal hier schaust

http://hsqldb.org/web/hsqlFeatures.html


wirst du feststellen, dass das was du über HSQLDB  schreibst, naja,.. 
nicht wirklich stimmt..

(siehe "disk tables"  with sync-on-commit  usw.)


scheinbar auch was die Performance angeht:
http://hsqldb.org/PolePosition.pdf

Robert L. schrieb:
> @ andras
>
> wenn du mal hier schaust
>
> http://hsqldb.org/web/hsqlFeatures.html
>
>
> wirst du feststellen, dass das was du über HSQLDB  schreibst, naja,..
> nicht wirklich stimmt..
>
> (siehe "disk tables"  with sync-on-commit  usw.)
>
>
> scheinbar auch was die Performance angeht:
> http://hsqldb.org/PolePosition.pdf

Ich sehe ich muss mich mal wieder mit dem Thema befassen...



mfg Andreas