Frage zur Datenbankwahl bei Umstieg auf Java

[Wellmeier]

Hallo zusammen,
ich bin über Google auf eure Seite gestoßen. Die Forensuche hat nichts brauchbares ergeben, aber vielleicht habe ich nach den falschen Stichwörtern gesucht.

Folgende Situation:
Ich habe bisher in einem Excel File Daten zu Personen gespeichert. Es sind rund 40 Personen und zu jedem wurde drei Datenblätter mit jeweils ca. 100 Daten (Nur Text) abgespeichert. Das dies in Excel geschah kam aus der Not heraus. Uns war schnell klar, dass eine Datenbank her müsste. Nun bin ich am überlegen, in welche Richtung ich gehen sollte.

Ich habe früher mit Access und ASP gearbeitet, dies kommt allerdings nicht in Frage. Das Problem ist nämlich, dass ich einerseits einen compilierten Programmcode für später möchte, damit den nicht jeder mitnimmt und verändert (auch wenn ich das mitnehmen kaum verhindern kann ). Andererseits muss das spätere Programm und die Datenbank auf einem Rechner laufen, auf dem wir nichts extra installieren können. Gestartet werden soll das Programm von einem Netzwerklaufwerk aus, auf dem die Daten auch liegen sollen, damit man sie von mehreren Rechnern (nicht zwingend gleichzeitig) im Netzwerk bearbeiten kann. Daher klappte Excel bisher auch so schön problemlos, ist aber nun endgültig an seinen Grenzen.

Ach so Access klappt auch nicht, da es schlicht dort nicht installiert ist.

Meine Frage ist nun, ob mein Gedanke, dies in Java mit der passenden Datenbank zu realisieren gut ist oder ob ihr meint, dass ich mich anderweitig umschauen sollte.

Sollte ich trotz der Forensuche doch den entscheidenden Beitrag übersehen haben, wäre ich für einen kurzen Link dankbar.

Gruß aus Hamburg
Janko

 

[Landei]

Da du Access schon ausgeschlossen hast, kannst du ja nicht mehr viel falsch machen

Ich würde an deiner Stelle erst einmal MySQL ausprobieren. Später zu einer anderen vernünftigen DB wechseln ist eigentlich kein Ding.

Der Zugriff von Java aus kann bei sehr kleinen Projekten über JDBC erfolgen, aber generell würde ich schon zu JPA oder Hibernate raten: Ein paar Annotationen, und schon übernimmt der EntityManager den ganzen Datenbank-Schrapel - das ist schon recht bequem (auch wenn Java nicht ganz an Microsofts LINQ herankommt).

 

[Wellmeier]

Hallo Landei,
vielen Dank für die Antwort. Das zeigt ja, dass ich zumindest gar nicht so falsch gedacht habt. Werde mich jetzt mal bei JPA. Hibernate und MySQL einlesen.

Ich lass das hier noch ein wenig offen, falls noch weitere Vorschläge kommen.

Gruß
Janko

 

[nillehammer]

Andererseits muss das spätere Programm und die Datenbank auf einem Rechner laufen, auf dem wir nichts extra installieren können. Gestartet werden soll das Programm von einem Netzwerklaufwerk aus, auf dem die Daten auch liegen sollen, damit man sie von mehreren Rechnern (nicht zwingend gleichzeitig) im Netzwerk bearbeiten kann.

MySQL muss als Server irgendwo installiert werden. Deswegen kommt es glaube ich für Dich nicht in Frage. Am ehesten wirst Du was mit embedded Java-DBs. Da gibt's mehrere, ich finde HSQLDB am besten.

 

[ThreadPool]

MySQL muss als Server irgendwo installiert werden.[...]

Das stimmt doch gar nicht. Es gibt eine MySQL noinstall Variante, da muss man nur 2-3 Optionen vorkonfigurieren und dann liefert man das ganze Geraffel als Zip zu seiner Software mit. Das Entpacken und an die richtigen Stellen kopieren kann man über einen Installer machen oder innerhalb des eigenen Programmes, das die Datenbank natürlich auch ordnungsgemäß startet und runterfährt. Man kann das sogar soweit treiben das die Datenbankdateien wg. der Schreibrechte im User-Ordner abgelegt werden und die Excecutables im Programmordner liegen, so machen wir das z.B.

 

[tfa]

Das Entpacken und an die richtigen Stellen kopieren kann man über einen Installer machen oder innerhalb des eigenen Programmes, das die Datenbank natürlich auch ordnungsgemäß startet und runterfährt. Man kann das sogar soweit treiben das die Datenbankdateien wg. der Schreibrechte im User-Ordner abgelegt werden und die Excecutables im Programmordner liegen, so machen wir das z.B.

Mit einer embedded Java-DB (ich bevorzuge H2) brauchst du auch das alles nicht. Kein Auspacken, Entzippen, Kopieren oder Hoch- und Runterfahren. Einfach ein JAR in den Klassenpfad und fertig.

 

[ThreadPool]

Mit einer embedded Java-DB (ich bevorzuge H2) brauchst du auch das alles nicht. Kein Auspacken, Entzippen, Kopieren oder Hoch- und Runterfahren. Einfach ein JAR in den Klassenpfad und fertig.

Da die Schritte nicht aktiv vom User gemacht werden müssen ist mir das egal. Des Weiteren ist ein JAR was wohl auch in einem externen Verzeichnis liegt das Äquivalent zum Executable und davon abgesehen müssen die Datenbankfiles, wenn man sie persistieren möchte auch irgendwo landen wo man schreiben darf. Den einzigen Vorteil den ich da gerade sehe ist das es mit den eingebetteten Lösungen etwas bequemer geht.

Aber darum ging es mir nicht sondern um die Widerlegung der Aussage das man MySQL zwanghaft installieren müsste.

 

[nillehammer]

Aber darum ging es mir nicht sondern um die Widerlegung der Aussage das man MySQL zwanghaft installieren müsste.

Und das war auch i.O., denn das wusste ich tatsächlich nicht. Das Muss-Kriterium "es darf nichts zu installieren sein" erfüllt dann wohl auch MySql. Aber abgesehen davon, kommt man mit embedded Java-DBs dem ürsprünglichen Nutzungsmodell "Excelfiles" am nächsten.