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.
JDBC wäre die Standardantwort, eventuell tuts aber auch was "leichtgewichtigeres" als Werkzeug.
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.
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.
für ein paar dämliche schülerdatensätze würde ich nicht noch eine extra datenbank ala mysql dazupacken sondern eine java-db nehmen deren code mit dem eigentlichen programm zusammengepackt werden kann. edit ---- grad mal geschaut weil ich selbst nur mit oracle und mysql erfahrung habe: http://java.sun.com/developer/technicalArticles/J2SE/Desktop/javadb/ edit2 ---- für dich evtl auch interressant http://java.sun.com/developer/technicalArticles/java_warehouse/single_jar/
>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
@ 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
Robert L. schrieb: > http://hsqldb.org/web/hsqlFeatures.html sieht richtig interressant aus :) http://hsqldb.org/web/usagelinks.html für einsteiger.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.