Datum Insert mit Überprüfung ob schon vorhanden in SQL-Datenbank

[Kirana]

Moin,

ich stecke grad mitten in einem Kleinprojekt und komme überhaupt nicht weiter. Lief bisher alles gut. Muß dazu sagen, bin blutige Anfängern was Java angeht, ich lerne grad FIAE in Umschulung und wir sind beim Abschlußprojekt für Java.

Ich erstelle ein Buchungssystem für eine Ferienwohnungvermietung. Jetzt geht es darum, das ich die normalen INSERT-Befehle fertig hab, aber diese überprüfen muß.

Sprich, wenn ich eine neue Buchung für einen best. Zeitraum für eine Ferienwohnung ausführen will, muß vorher gecheckt werden, ob dieser Zeitraum bereits belegt ist. Mit der normalen DATE Funktion komme ich nicht weiter...

Ich muß die bestehenden Daten in der SQL-Tabelle als String in Java auslesen, womit ich schon Probleme krieg, weil er natürlich ein INT erwartet und keinen STRING. Meine neuen Daten werden in ein Feld eingetragen, das ein STRING ausliest.

Diese Daten müssen in die Datenbank, nach der Abfrage, ob der Zeitpunkt belegt ist. Hab schon gegoogelt ohne Ende, auch in "Java ist auch eine Insel" openbook gestöbert, aber keine wirkliche Lösung für mein DATUMproblem gefunden.

Hat jemand einen Tipp, wo ich noch Informationen zum überprüfen von DATUMsfunktionen per String über Java finden kann ?

Ich muß praktisch beim reinschreiben in die DB checken, ob der neue Anreisetag kleiner als der bereits bestehende Anreisetag und grösser als der Abreisetag ist...

Kleines Beispiel:

vom 20.4.-9.5. ist Ferienwohnung 1 bereits belegt.

Gebe ich jetzt für Ferienwohnung 1 einen neuen INSERT ein, der in dem Zeitraum liegt, geb ich ne JOptionPane aus "Bereich ist bereits belegt". Ist der Zeitraum noch frei, kann gebucht werden, also vor dem 20.4. und nach dem 9.5. ist die Wohnung wieder frei.

Dies muß doch mit einer Schleife und den nötigen PARAMETERN möglich sein.

Ich hoffe es kann mir jemand helfen. Ich arbeite mit Netbeans 6.8, falls das dazu wichtig ist zu wissen.

Liebe Grüsse

Kirana

[kingofbrain]

Guten Morgen!

Ich verstehe nicht, warum Du mit Strings arbeitest. Ist das eine Forderung des "Auftraggebers"? Felder mit Datumsinhalten sollten in der Datenbank auch als DATE oder TIMESTAMP (wenn die Uhrzeit wichtig ist) gepflegt werden.

Wenn Du mit Strings arbeiten *musst*, dann wirst Du im Java-Programm ja vermutlich mit java.util.Date arbeiten. Wenn Du aus einem solchen Date einen String machen willst, oder aus einem String ein Date, dann hilft Dir die Klasse java.text.SimpleDateFormat. Mit dieser kannst Du anhand eines Musters (z.B. "dd.MM.yyyy") angeben, wie der String aussieht oder aussehen soll, den Du verarbeiten oder erzeugen willst.

Kurzer Einwand von Edith: Zweiteres sollte nicht pauschal gemacht werden. Es gibt einen Grund, warum Datums (Datümer, Daten ) als DATE in der DB abgelegt werden. Das sollte der Standardfall sein. Nur bei einer Anwendung in einem bereits bestehenden Datenmodell, in dem aus historischen Gründen (oder Unfähigkeit der Entwickler) Vermurksungen in den Feldtypen gegeben sind, muss man sich hier mit einer solchen Krücke behelfen.

Schöne Grüße,

Peter

[Kirana]

Hallo Peter

danke für deinen Tipp. Das ist kein Projekt meines AGs, ich bin in einer Umschulung und habe mir für mein Java-Abschluß-Projekt (wir haben 3 Wochen Zeit dafür) ausgesucht, ein Belegungs- und Buchungssystem für eine Ferienwohnungsvermietung zu erstellen.

Das auslesen der DB funktioniert auch einwandfrei... das gibt er in einer Tabelle mit SELECT * FROM ... aus... wie gewohnt auch über java.

Und nun hab ich eine Maske, in der man Buchungen hinzufügen kann. Also für einen Gast, der eine Wohnung buchen möchte, kann man dort aussuchen, für welchen Zeitraum die jeweilige Ferienwohnung reserviert werden soll.

Als Anreise- und Abreisedatum hab ich Textfelder erstellt, die passenderweise nun auch jT_anreise und jT_abreise heißen. Dort wird das Datum eingegeben. Beim absenden sollen diese Daten in die DB übernommen werden.

Die Tabelle in der DB hat bereits (von mir beispieldaten) Datensätze mit Daten drin, bsp.weise:

Anreisetag Abreisetag

2010-04-01 2010-04-14

2010-05-13 2010-05-26 usw...

jede Ferienwohnung hat ihre eigenen Daten, die über IDs miteinander in der Belegungstabelle mit dem jeweiligen Gast belegt sind.

Für einen neuen Gast, der genau in diese Ferienwohnung reinmöchte, muß ja erst gecheckt werden, ob der Zeitraum, wo er reinmöchte, noch frei ist. Und das war bisher mein Problem...

String to Date deshalb, damit er den eingegebenen Wert in dem Textfeld jT_anreise bsp.weise als Datum erkennt und abchecken kann. Ich wüßte sonst nicht, wie ich das herausbekommen kann, ob der Zeitraum bereits belegt ist oder nicht.

Mit SimpleDateFormat hab ich es bereits versucht, doch war das nicht die Lösung, die ich gebraucht hab...

[LadyPreis]

Ungetestet:

Ersetz doch deine jTextFields durch JSpinner-Komponenten. Diesen gibts du dann ein neues JSpinner-Date-Model mit. Dann kannst du den enthaltenen Value in ein Date-Objekt casten. Damit solltest du dann auch vernünftig eine Abfragae auf die in der DB enthaltenen Werte hinbekommen

[kingofbrain]

Deshalb habe ich den "Auftraggeber" ja auch in "" gesetzt (der ist halt bei Dir ein Dozent).

Leider kann ich aus Deiner umfangreichen Beschreibung keinen konkreten Fehler entnehmen. Was hast du probiert, was hast Du erwartet, was hast Du bekommen?

Wenn Du sagst, SimpleDateFormat hilft Dir nicht: warum (Detailfragen siehe oben)?

Steht in der DB jetzt ein CHAR / VARCHAR oder ein DATE (was vom SQL-Client Deiner Wahl angezeigt wird, ist egal, die Felddefinition in SQL ist relevant)?

Schöne Grüße,

Peter

[Kirana]

Danke Lady für den Tipp. Ich konnte ihn teilweise übernehmen. Hab ein Model zu Hilfe genommen. Und alles in einen Vector gepackt.

Und anstatt Anfangs- und Enddatum hab ich Anfangsdatum plus Tage bis Enddatum genommen und nun klappts.

Danke auch dir Peter... ich bin erstaunt wie schnell mir hier geholfen wird. Mein Programm läuft soweit es soll und nun kann ich endlich die Projektbeschreibung und die Präsentation machen...

Mit SimpleDateFormat hat er mir immer wieder gesagt, das er ein DATE erwartet und ein STRING erhält... nur intern in Java hats nicht funktioniert. Die Abfragen in der Datenbank haben funktioniert.

Ich habe für das Datum ein DATE in der SQL genutzt, die ID waren selbstverständlich INTEGER und die Bezeichnungen dann als VARCHAR.

Ich hab keine Rückgabe gehabt, er hat die Anwendung gar nicht ausgeführt... aber jetzt geht es... ich brauchte nur den Tipp mit dem Model und dann kam ich selbst drauf, nachdem ich noch bissl gegooglet hab.

Vielen Dank euch... nun weiß ich wo ich nachfragen kann wenn ich HIlfe brauche. Beim nächsten mal sende ich auch gleich den CODE mit, damit ihr direkt wißt, was ich meine.. entschuldigt mein kompliziertes Vorgehen, ich hab hier noch nicht so viele Beiträge verfasst.

Nochmal danke und eine schöne Osterwoche wünsche ich euch allen!

[MartinSt]

Ich muß praktisch beim reinschreiben in die DB checken, ob der neue Anreisetag kleiner als der bereits bestehende Anreisetag und grösser als der Abreisetag ist...

Das reicht leider nicht; wenn ein angefragter Zeitraum komplett in einem schon gebuchten Bereich enthalten ist, soll er ja auch nicht buchbar sein, also z.B. angefragt wird 12.4.-17.4.2010 aber die FeWo ist bereits für den kompletten April gebucht. Außerdem kann es ja sein, dass sich die angefragte Zeit mit ZWEI (oder mehr) aufeinanderfolgenden bestehenden Buchungen überschneidet.

[flashpixx]

Das reicht leider nicht; wenn ein angefragter Zeitraum komplett in einem schon gebuchten Bereich enthalten ist, [...] Außerdem kann es ja sein, dass sich die angefragte Zeit mit ZWEI (oder mehr) aufeinanderfolgenden bestehenden Buchungen überschneidet.

Genau, da kann ich mich nur anschließen. Die meisten DBMS unterstützen ein Schlüsselwort "between" mit dem man so etwas prüfen kann. D.h. man prüft bevor man den neuen Datensatz fügt, ob eben schon einer existiert.

Ich rate ganz dringen hier, diese Prüfung mittels Trigger zu lösen, damit der Datenstamm konsistent bleibt. Eine Prüfung innerhalb der Anwendungslogik ist nicht sinnvoll.

[dr.dimitri]

Ich rate ganz dringen hier, diese Prüfung mittels Trigger zu lösen, damit der Datenstamm konsistent bleibt. Eine Prüfung innerhalb der Anwendungslogik ist nicht sinnvoll.

Davon rate ich wiederum dringendst ab, denn zum einen kann ein Trigger auch nicht mehr als Du aus der Anwendung heraus, zum anderen kannst Du bei einem Row Level Trigger nicht auf die sich gerade ändernde Tabelle selektieren, Du siehst auch in einem Trigger keine Änderungen die gerade von einer anderen Session geschrieben aber noch nicht committed wurden und last but not least ist es absolut schlechter Stil Programmlogik in einem Trigger zu verstecken (mal davon abgesehen, dass es Datenbanken gibt, die keine Trigger unterstützen).

Wenn dann macht eine solche Prüfung nur in der Programmlogik Sinn und zwar kombiniert mit optimistischem Locking sofern die Anwendung Multiuserfähig sein soll.

Dim

[flashpixx]

Wenn dann macht eine solche Prüfung nur in der Programmlogik Sinn und zwar kombiniert mit optimistischem Locking sofern die Anwendung Multiuserfähig sein soll.

Diese Aussage widerspricht dem Konzeptionellen Schemas vgl. hierzu "Datenbanksysteme" von Prof Kemper & Dr Eickler Seite 165ff / Kpitel 5.3

Wenn solche Prüfungen innerhalb der Anwendungslogik wären, dann würde dies den Code unnötigerweise auf blähen und viel anfälliger gegen Fehler machen, denn wenn die Anwendung unterschiedliche Release Stände hat und ein Fehler innerhalb eines Stands enthalten ist, dann würde die Datenbank inkonsistent werden. Somit gehören rein aus der Konsistenz her, solche Prüfungen in die Datenbank, wie man das nun konkret umsetzt ist natürlich vom DBMS abhängig

[dr.dimitri]

Diese Aussage widerspricht dem Konzeptionellen Schemas vgl. hierzu "Datenbanksysteme" von Prof Kemper & Dr Eickler Seite 165ff / Kpitel 5.3

Dann haben die Herren, mit Verlaub gesagt, von diesem Thema entweder nicht die geringste Ahnung, oder aber, da ich das Buch nicht kenne, Du hast eine Aussage falsch wiedergegeben. Aber ich glaub ich bestell mir das mal und schau selbst nach was den zukünftigen Entwicklern heute so beigebracht wird. :upps

Wenn solche Prüfungen innerhalb der Anwendungslogik wären, dann würde dies den Code unnötigerweise auf blähen und viel anfälliger gegen Fehler machen

Aha. Ist das Deine Aussage oder ein Zitat aus obigem Buch?

denn wenn die Anwendung unterschiedliche Release Stände hat und ein Fehler innerhalb eines Stands enthalten ist, dann würde die Datenbank inkonsistent werden.

Klar klingt logisch. In einem Trigger ist die Prüfung natürlich per Definition immer fehlerfrei. Wir sollten viel mehr Logik in einem Trigger hinterlegen. Dann werden auch die Anwendungen wartbarer. Was passiert eigentlich, wenn jemand diesen Trigger abschaltet? Dann ist es vorbei mit der Konsistenz und das ohne, dass irgend jemand etwas merken muss und/oder es eine programmänderung gegeben hat.

Somit gehören rein aus der Konsistenz her, solche Prüfungen in die Datenbank

Fachliche Plausibilisierungen gehören in die Anwendung. Diese kann in einem AppServer, im Client oder als PL/SQL Prozedur in der DB laufen - je nach Architektur der AW eben. Aber sie gehört auf keinen Fall in einen Trigger, der ohne weiteres zutun, ohne je im Programm irgendwo aufgerufen zu werden auf magische Art und Weise Dinge erledigt - oder auch nicht wenn er abgeschaltet wird.

Behauptet jemand, das solche Logik grundsätzlich in einen Trigger gehört, ist diese schlicht und einfach falsch - das wird dir jeder Datenbankentwickler mit Erahrung in fachlich komplexen Anwendungen bestätigen können.

Des weiteren können, wie schon erwähnt, bestimmte Dinge in einem Trigger überhaupt nicht gemacht werden. Dazu gehört z.B. auch, dass man in einem Row Level Trigger auf Tabelle A nicht auf Tabelle A selektieren kann. Die Datenbank wird das abblocken (in Oracle der Fehler ORA-04091). Für Konsistenzprüfungen dürte das aber eine nicht unerhebliche Einschränkung sein.

Ganz schlimm wird es übrigends, wenn Datenbankconstraints (RI, Check, Unique, NOT NULL) mittles Trigger nachprogrammiert werden. Steht das auch in diesem Buch?

Dim