MySQL Select und Insert in Java

[Anesa]

Hallo ihr lieben und ich hoffe ihr könnt mir bei meinem Problem helfen.
Ich habe eine Datenbank (liste nur das auf was derzeit mein problem betrifft)
Es geht um ein Hotel.
Ich habe eine Tabelle Zimmer mit den Spalten Zimmer_ID, Bezeichnung und Art.
Unter Art sind "einzel" und "doppel" Zimmer, die nötige anzahl an den jeweiligen Zimmern sind in der Datenbank schon vorhanden.
Die zweite Tabelle ist buchung. Dort sind die Spalten FK_Zimmer_ID mit verknüpfung zur Zimmer_ID, Anreise und Abreise als Date.

Nun möchte ich in meinem Java-Code ein Select bzw. Insert schreiben das in meiner DB schaut in buchungen welche Zimmer belegt sind um dann die passenden einzel bzw. doppelzimmer zu buchen die gerade gebraucht werden.

Als Bsp.: ein Gast bucht 1 einzel und 1 doppelzimmer, in DB schauen was frei ist um dann 1 einzel und ein doppelzimmer zu buchen.
Versuche schon seit ein paar Tagen mich daran aber bekomme es irgendwie nicht hin.
Ich hoffe sehr das ihr mir bei meinem Problem helfen könnt.

 

[mihe7]

ein Gast bucht 1 einzel und 1 doppelzimmer

Das sind zwei Buchungsanfragen, wobei der Zeitraum fehlt. Je Anfrage gibt es drei Parameter: die gewünschte Anreise, Abreise, und Zimmerart (:g_anreise, ...)

SELECT * FROM zimmer
 WHERE art = :g_art
   AND zimmer_id NOT IN (
    SELECT zimmer_id FROM buchung
     WHERE :g_anreise < abreise 
       AND :g_abreise >= anreise
    )

Das packst Du in ein PreparedStatement, setzt die Parameter, führst die Abfrage aus und kannst dann über ein ResultSet mit den freien Zimmern iterieren.

 

[Dukel]

Unter Art sind "einzel" und "doppel" Zimmer, die nötige anzahl an den jeweiligen Zimmern sind in der Datenbank schon vorhanden.

Was passiert, wenn das Hotel Mehrbettzimmer (drei Betten oder noch mehr) baut?
Ich würde das eher als Int machen und nicht Art nennen.

 

[mihe7]

@Dukel man kann die Zimmerart nicht aus der Zahl der Betten ableiten. Beispiel: Zweibettzimmer vs. Doppelzimmer

 

[Dimax]

DELIMITER //

CREATE FUNCTION FindeZimmer( :g_art VARCHAR  )
RETURNS INT

BEGIN

   DECLARE zimmer_id  INT;

 SET zimmer_id =   
(SELECT zimmer_id FROM zimmer
 WHERE art = :g_art
   AND zimmer_id NOT IN (
    SELECT zimmer_id FROM buchung
     WHERE :g_anreise < abreise 
       AND :g_abreise >= anreise
    ))

   RETURN zimmer_id;

END; //

DELIMITER ;

INSERT into buchung values (FindeZimmer(:g_art),usw.....

 

[mihe7]

@Dimax gibt das nicht ein Problem, wenn es mehr als ein freies Zimmer gibt?

 

[Thallius]

Ausserdem würde ich dringend empfehlen statt dem subselect doch lieber mit join zu arbeiten...

 

[mihe7]

Du meinst einen outer join und Prüfung auf null?

 

[Dimax]

mihe7 da gibt es mehr Probleme als Lösungen,klar man muss die Funktion anpassen,wollte nur die Richtung zeigen)

 

[Neumi5694]

Ausserdem würde ich dringend empfehlen statt dem subselect doch lieber mit join zu arbeiten...

Also bei großen Tabellen würde ich dem widersprechen, es sei denn, dass MySql die Abfrage noch optimiert und die Bedingungen vor dem join ausführt.

 

[mihe7]

Ich musste vor kurzem feststellen, dass MySQL ziemlich bescheiden ist, was Optimierungen bzgl. GROUP BY in Views betrifft: da wird gar nix optimiert :-(

 

[Thallius]

Wäre interessant das mal auszuprobieren. Aber wäre schon ein extremes Armutszeugnis wenn er wirklich erstmal alles joined um es dann mit dem where wieder rauszuwerfen. Das kann ich mir nicht vorstellen.

Gruß

Claus

 

[Neumi5694]

Womit wir bei MS-Access wären

 

[mihe7]

Wäre interessant das mal auszuprobieren. Aber wäre schon ein extremes Armutszeugnis wenn er wirklich erstmal alles joined um es dann mit dem where wieder rauszuwerfen. Das kann ich mir nicht vorstellen.

Das kannst Du gerne machen. Im Wesentlichen ging es um eine (etwas kompliziertere als hier dargestellte) Abfrage der Art

SELECT * FROM (SELECT bill_id, sum(price) total FROM bill_pos GROUP BY bill_id) x WHERE x.bill_id = 123;

Wobei der Subselect tatsächlich als View vorlag und auf bill_id natürlich ein Index liegt. Man hätte erwartet, dass der Optimierer daraus

SELECT bill_id, sum(price) total FROM bill_pos WHERE bill_id=123 GROUP BY bill_id

bastelt. Tatsächlich wurde aber erst

SELECT bill_id, sum(price) total FROM bill_pos GROUP BY bill_id

ausgeführt und dann aus dem Ergebnis die Zeile mit bill_id 123 ermittelt

 

[Thallius]

Deswegen sage ich ja subselects nur benutzen wenn es nicht anders geht. Mit denen habe ich bisher auch nur schlechte Erfahrungen gemacht. Bei mir waren joins immer um ein wesentliches schneller...

 

[mihe7]

Wenn das Problem nur am Subselect liegen würde (den habe ich hier nur zur Verdeutlichung verwendet): der Spaß tritt ja auch auf, wenn Du den inneren SELECT als View anlegst und diese verwendest: SELECT * FROM bill_sums WHERE id = 123;

Das Fazit, das ich daraus gezogen haben: verwende für die Anwendung keine Aggregate-Views mit MySQL.

Vielleicht haben sie das in neueren MySQL-Versionen auch schon behoben. Falls nicht: die Lösung wäre vermutlich, eine Rewrite-Engine zu verwenden. Aber ganz ehrlich: bevor ich da neue Komponenten einführe, die irgendwas im Hintergrund veranstalten, baue ich den SELECT lieber in der Anwendung zusammen.