Hallo,
ich habe vor, eine Anwendung zur Schülerverwaltung in Java zu schreiben
(mit Benutzeroberfläche). Die Schülerdaten sollen dabei in einer
Datenbank (vielleicht MYSQL??) abgelegt werden.
Herauskommen soll eine Datenbankanwendun samt Installationsroutine.
Ich hab mit Datenbanken und Java bereits zu tun gehabt, weiß aber nicht
wie ich beides unter einen Hut bringen kann bzw. wie ich an die Sache
ran gehen soll?
Weiß von Euch jemand einen guten Link, Buch etc...
Wäre sehr dankbar, viele Grüße, Sebastian.
Schaue dir SQL Lite an, ist einfacher zu handeln als beim Installieren
MySQL mitzuinstallieren. Wenn deine Entwicklungsumgebung keine Install's
erstellen kann, gibt es dafür genügend Freeware.
Ich würd auch HSQLDB empfehlen. Ist embedded wie SQlite, aber
vollständig in Java und hat solides ANSI SQL mit Triggern, Stored
Procedures und allem was halt so zu ner echten SQL-Datenbank gehört.
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
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.)
>>>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
korrekt. möglicherweise solls auch ein ha cluster mit
indexpartitionierung und transaktionsicherem online-backup werden... wer
weiß.
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.
richtig, aber vielleicht kann der TO sich einen haufen ärger/arbeit
sparen wenns wirklich nur ein paar popelige datensätze sind. die antwort
ob java db oder jdbc und externe db richtet sich imho danach ob das
projekt mal "groß" werden will.
wenn nicht ist das mitschippern und installieren einer externen db viel
zu viel huddel.
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
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
Eine eigene Frage?
Dieser Thread ist über 14 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
