# Fakturierungsprogramm - Daten aktuell halten (blutiger Anfänger)



## sven-meye (5. Jul 2015)

Hallo zusammen
Ich besitze die grundlegenden Java-Kenntnisse. Nun habe ich als Semesterarbeit den Auftrag für ein kleines Fakturierungsprogramm bekommen. Da dieses in einem Betrieb mit einigen Mitarbeitern eingesetzt werden soll, stellt sich mir nun die Frage der Datenverwaltung. Die Daten sollten ja immer aktuell sein.

Nun hatte ich mir überlegt (Ihr werdet wahrscheinlich lachen), das die Daten einfach bei jeder Aktion aktualisiert werden, damit sie mehr oder weniger aktuell sind.

-> Benutzer 1 & 2 öffnen das Programm.
-> Sehen den aktuellen Datenstand (10 Datensätze)
-> Benutzer 1 bearbeitet Datensatz 5 & 7 und erstellt einen neuen Datensatz (11)
-> Benutzer 2 bearbeitet ebenfalls Datensatz 5 und erstellt ebenfalls einen neuen Datensatz (11)
-> Benutzer 1 speichert (& aktualisiert dadurch) ab, sieht nun seine Änderungen (seinen Datensatz 11 & die Änderungen an 5 & 7)
-> Benutzer 2 speichert (& aktualisiert dadurch) ab, sieht nun seine Änderungen an Datensatz 5 (da er die von Benutzer 1 überspeichert) und die Änderungen an Datensatz 7, sieht den Datensatz 11 (von Benutzer 1, da er zuerst war) und seinen neuen Datensatz als 12 (beim Speichern werden die Daten neu geladen, deshalb springt er auf 12 weil 11 schon existiert).

Ich denke, dass sollte relativ gut funktionieren. Allerdings ist das wahrscheinlich eine sehr unschöne Methode. Da bei vielen Datensätzen zu Ladezeiten usw. kommen könnte und ein hoher Datenverkehr entsteht.

Nun wollte ich fragen ob es eine bessere Methode gibt? Oder kann man es bei wenigen Mitarbeitern so umsetzen? Oder sollte ich es lieber komplett lassen? Da ich wie bereits ein blutiger Anfänger auf dem Gebiet bin, freue ich mich über jede Antwort!

Vielen Dank im Voraus

sven-meye


----------



## nvidia (6. Jul 2015)

Naja ich würde das als gute Übung sehen aber definitiv nicht in einem echten Unternehmen einsetzen wollen wenn du wie du sagst blutiger Anfänger bist. Ein Semester ist nicht lang und man hat ja noch genug anderen Kram während des Semesters zu erledigen, was als Endprodukt dann herausfällt ist eher fraglich. 

Persönlich würde ich es ungefähr so gestalten (Fat-)Client <--(vll. per RMI (Simon etc.)--> Serverkomponente <-> Datenbank. Wenn du dich jetzt fragst weshalb da noch einen "Server" dazwischen schieben, ganz einfach wg. Multi-User und Benachrichtungsmöglichkeiten. Hat man nur Client <--> DB wird man sich bzgl. Multiuser früher oder später irgendein Lockingmechanismus selbst bauen usw. das muss man nicht haben. 
So hat man auch die Möglichkeit das man allen Clients Bescheid geben kann wenn irgendeiner was geändert hat ohne irgendwelche Trigger oder Eventmechanismen von der DB verwenden zu müssen oder nicht alle x-Sekunden/Minuten bei der Datenbank nachfragen ob denn schon etwas da ist. Und das ist ja das was du möchtest. Des Weiteren wenn die Serverkomponente nicht läuft kann keiner Unfug mit der DB anstellen.

Für die SQL-Seite würde mir auch keinen ORM-Mapper wie Hibernate ans Bein binden, du kannst in der Datenzugriffschicht ziemlich schlank mit DAOs arbeiten. Und SQL-Statements als Text müssen heute auch nicht mehr im Code stehen, sowas kann man wartbar mit z.B. einer kleinen DSL wie wie Free downloads and pricing for jOOQ umgehen.


----------

