Ankündigung

Einklappen
Keine Ankündigung bisher.

Datenbank Design für eine Buchungsseite ( Ferienwohnung vermieten)

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • #31
    Erstmal schönen Dank! Bis dort hin war ich jetzt allerdings auch schon gekommen. Es funktioniert nur nicht, sprich: Ich kann nicht auf den Modus "ONLY FULL GROUP BY" umschalten. Tw. liegt es an den vorgeschlagenen Befehlen (selbst die im MySQL-Manual genannten funktionieren tw. nicht), tw. an meinen Fehlern bei der Eingabe.

    Ich mache weiter und berichte. Jedenfalls ist jetzt klar, warum die Abfrage aus #29 bei mir "durchgeht".

    Kommentar


    • #32
      So, Ergebnis. Man kann das Verhalten von MySQL umschalten, und zwar unter "Variablen" im phpmyadmin. Stellt man die Variable "sql_mode" auf "ONLY_FULL_GROUP_BY", wird die in #29 genannte Abfrage nicht ausgeführt, sondern ergibt die Fehlermeldung
      #1055 - 'auktion_db.gebote.kunde' ist nicht in GROUP BY vorhanden
      In den von Meister1900 genannten Quellen wird dann auch die "Duldung" von "überzähligen" Spalten in der Select-Feldliste bei aktiver ONLY_FULL_GROUP_BY-Einstellung erläutert. Sie ist gleichlautend mit meiner Begründung, Stichwort: funktionale Abhängigkeit, das kann man ja dann nachlesen.

      Fazit: MySQL macht nichts falsch oder richtig, sondern überläßt es dem User = Entwickler, selbst zu entscheiden.

      So, und jetzt schnell wieder das ONLY_FULL_GROUP_BY deaktivieren...

      Kommentar


      • #33
        marie123 oder auch alf2016
        Schön für dich, dass du einen bereits seit mehreren Jahre aktivierten Modus erkannt hast... Ich hatte gehofft, dass hier über das Datenbankdesign einer Buchungsseite geschrieben wird. Du zerstörst hier fast jeden Daba-Thread - warum?

        Kommentar


        • #34
          Um wieder zum Thema zu kommen zeige ich mal, was man z.B. mit den Mitteln von PostgreSQL machen könnte:

          Code:
          --
          -- Tabelle für Buchungen der Fewo.
          -- hier mit Datenrange und exclusion constraint, damit ein und dieselbe Fewo nicht überbelegt werden kann
          -- Range-typen und exclusion constraints sind coole Erweiterungen von PG, GiST-Indexe können Überlappungen prüfen, z.B. auch bei Geometrien
          --
          
          test=# create table fewo_buchung(wohnung int, von_bis daterange, exclude using gist(wohnung with =, von_bis with &&));
          CREATE TABLE
          
          --
          -- Preistabelle
          -- hier mit Datumsbereichen, wann welcher Preis gelten soll
          --
          
          test=*# create table fewo_kosten (id int primary key, von_bis daterange, preis int, exclude using gist(von_bis with &&));
          CREATE TABLE
          test=*# insert into fewo_kosten values (1, '[2019-01-01, 2019-04-01)', 20);
          INSERT 0 1
          test=*# insert into fewo_kosten values (2, '[2019-04-01, 2019-11-01)', 30);
          INSERT 0 1
          test=*# insert into fewo_kosten values (3, '[2019-11-01, 2019-12-20)', 20);
          INSERT 0 1
          test=*# insert into fewo_kosten values (4, '[2019-12-20, 2020-01-05)', 40);
          INSERT 0 1
          
          --
          -- jetzt belege ich mal einige Fewo's
          --
          test=*# insert into fewo_buchung values (1, '[2019-03-20, 2019-04-04)');
          INSERT 0 1
          test=*# insert into fewo_buchung values (1, '[2019-06-15, 2019-06-25)');
          INSERT 0 1
          test=*# insert into fewo_buchung values (1, '[2019-12-15, 2020-01-03)');
          INSERT 0 1
          
          --
          -- hier die Inhalte der zei Tabellen
          --
          test=*# select * from fewo_kosten ;
           id |         von_bis         | preis
          ----+-------------------------+-------
            1 | [2019-01-01,2019-04-01) |    20
            2 | [2019-04-01,2019-11-01) |    30
            3 | [2019-11-01,2019-12-20) |    20
            4 | [2019-12-20,2020-01-05) |    40
          (4 rows)
          
          test=*# select * from fewo_buchung ;
           wohnung |         von_bis         
          ---------+-------------------------
                 1 | [2019-03-20,2019-04-04)
                 1 | [2019-06-15,2019-06-25)
                 1 | [2019-12-15,2020-01-03)
          (3 rows)
          
          --
          -- ein View
          -- übrigens mit einem LATERAL JOIN. Definiert vom SQL-Standard, nicht implementiert in z.B. MySQL
          --
          test=*# create view kalkulation as (with tmp as (select b.*, b.von_bis * k.von_bis as preiszeitraum, k.von_bis as preiszeit, k.preis from fewo_buchung b left join lateral (select * from fewo_kosten x where b.von_bis && x.von_bis) k on true) select wohnung, von_bis, preiszeit, upper(preiszeitraum) - lower(preiszeitraum) as tage, preis from tmp);
          CREATE VIEW
          test=*# select * from kalkulation ;
           wohnung |         von_bis         |        preiszeit        | tage | preis
          ---------+-------------------------+-------------------------+------+-------
                 1 | [2019-03-20,2019-04-04) | [2019-01-01,2019-04-01) |   12 |    20
                 1 | [2019-03-20,2019-04-04) | [2019-04-01,2019-11-01) |    3 |    30
                 1 | [2019-06-15,2019-06-25) | [2019-04-01,2019-11-01) |   10 |    30
                 1 | [2019-12-15,2020-01-03) | [2019-11-01,2019-12-20) |    5 |    20
                 1 | [2019-12-15,2020-01-03) | [2019-12-20,2020-01-05) |   14 |    40
          (5 rows)
          
          
          --
          -- Aufsummierung
          --
          
          test=*# select wohnung, von_bis, sum(tage*preis) from kalkulation group by wohnung, von_bis order by von_bis;
           wohnung |         von_bis         | sum
          ---------+-------------------------+-----
                 1 | [2019-03-20,2019-04-04) | 330
                 1 | [2019-06-15,2019-06-25) | 300
                 1 | [2019-12-15,2020-01-03) | 660
          (3 rows)

          Für die Freunde von MySQL: bekommt ihr das auch hin?


          PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

          Kommentar


          • #35
            Zitat von akretschmer Beitrag anzeigen
            Um wieder zum Thema zu kommen ...

            Hatte der TE nicht um Hilfe bei der Entwicklung seines DB- bzw. Daten-Modells gebeten? LordMustang hast du inzwischen die Punkte erledigt, um die ich dich in #9 gebeten hatte?

            Kommentar


            • #36
              Zitat von akretschmer Beitrag anzeigen
              Für die Freunde von MySQL: bekommt ihr das auch hin?
              Soweit geht die Freundschaft dann doch nicht.
              Aber mal im Ernst, wir hatten das Thema Datumsüberschneidungen und auch Buchungen, Termine, etc. hier schon öfter und es ist mit normalen Mysql-Bordmitteln nur schwer nachzubauen und zudem wesentlich fehleranfälliger.

              Dafür das er sich das als Übungsaufgabe gesetzt hatte, hast du ihm ja schon viel davon abgenommen was man üben könnte, aber dennoch schön gemacht, chapeau.


              Kommentar


              • #37
                Zitat von marie123 Beitrag anzeigen
                So, Ergebnis. Man kann das Verhalten von MySQL umschalten, und zwar unter "Variablen" im phpmyadmin. Stellt man die Variable "sql_mode" auf "ONLY_FULL_GROUP_BY", wird die in #29 genannte Abfrage nicht ausgeführt, sondern ergibt die Fehlermeldung
                Ok, aber das ist dann eine fehlerhafte Konfiguration von phpMyAdmin, MySQL setzt diese Einstellung, wie bereits erwähnt seit längerem schon per default korrekt.
                Wenn ThirdParty-Tools diese sinnfrei überschreiben, darf man das aber nicht MySQL anlasten

                Competence-Center -> Enjoy the Informatrix
                PHProcks!Einsteiger freundliche TutorialsPreComposed Packages

                Kommentar


                • #38
                  Zitat von Arne Drews Beitrag anzeigen
                  Ok, aber das ist dann eine fehlerhafte Konfiguration von phpMyAdmin, MySQL setzt diese Einstellung, wie bereits erwähnt seit längerem schon per default korrekt.
                  Wenn ThirdParty-Tools diese sinnfrei überschreiben, darf man das aber nicht MySQL anlasten
                  Du verstehst da einiges falsch. Aber die ganze Diskussion gehört hier eigentlich nicht hin, was du ja oben bereits kritisiert hast (#24). Ich bin gerade dabei in dem Thread, in dem das Problem aufkam ( https://www.php.de/forum/webentwickl...reach-schleife ), diese Diskussion zusammenzufassen und schlage vor, deine Fragen/Beiträge dort anzubringen.

                  Kommentar


                  • #39
                    Zitat von protestix Beitrag anzeigen
                    ... aber dennoch schön gemacht, chapeau.
                    um ehrlich zu sein: ich bereite gerade eine Schulung für einen Kunden vor, bei der ich mal so einige Features von PostgreSQL zeigen will. Range-Typen, Exclusion-Constraint, Lateral Join. Bot sich einfach an
                    PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

                    Kommentar


                    • #40
                      Zitat von akretschmer Beitrag anzeigen
                      Für die Freunde von MySQL: bekommt ihr das auch hin?
                      https://www.db-fiddle.com/f/kjvrmseJ5z4YHnZ5mdmAnh/0

                      Die Tabelle mit dem Datum kann man auch im Query "erzeugen", aber das wird richtig abartig.

                      Zitat von chorn Beitrag anzeigen
                      Wenn mir eine Datenbank, ohne dass ich explizit mit RAND() etc danach gefragt habe, willkürlich Ergebnisse liefert, dann ist sie für mich kaputt.
                      Dann ist jede Datenbank kaputt die SQL spricht. Ein SELECT ohne ORDER BY ist per Definition willkürlich.

                      Kommentar


                      • #41
                        erc : da fehlt noch der exclusion constraint, aber ich bin mal großzügig
                        PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

                        Kommentar


                        • #42
                          Zitat von akretschmer Beitrag anzeigen

                          Für die Freunde von MySQL: bekommt ihr das auch hin?
                          Nein so nicht.

                          Das beschäftgt mich eh schon länger

                          Bspw. Hotel

                          Zimmer 1 belegt vom 1.1 - 5.1 und 10.1-18.1
                          Zimmer 2 belegt vom 1.1 - 7.1 und 14.1 -18.1

                          Buchungsanfrage 6.1 -13.1...



                          Kommentar


                          • #43
                            Zitat von kaminbausatz Beitrag anzeigen

                            Nein so nicht.

                            Das beschäftgt mich eh schon länger

                            Bspw. Hotel

                            Zimmer 1 belegt vom 1.1 - 5.1 und 10.1-18.1
                            Zimmer 2 belegt vom 1.1 - 7.1 und 14.1 -18.1

                            Buchungsanfrage 6.1 -13.1...


                            war das jetzt irgendwie an mich gerichtet?
                            PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

                            Kommentar


                            • #44
                              Zitat von akretschmer Beitrag anzeigen
                              erc : da fehlt noch der exclusion constraint, aber ich bin mal großzügig
                              Vielen Dank Die constraints kann ich dir auch als Trigger implementieren. (vermuttlich) Aber sind wir mal ehrlich, wer will Geschäftslogik in Mysql implementieren?! Ich nicht...

                              Zitat von kaminbausatz Beitrag anzeigen
                              Nein so nicht.

                              Das beschäftgt mich eh schon länger

                              Bspw. Hotel

                              Zimmer 1 belegt vom 1.1 - 5.1 und 10.1-18.1
                              Zimmer 2 belegt vom 1.1 - 7.1 und 14.1 -18.1

                              Buchungsanfrage 6.1 -13.1...
                              Schaust dir den letzten Beitrag von mir an. Zerleg die Datumsbereiche in Tage und das geht Problemlos.

                              PHP-Code:
                              SELECT
                                 datum
                              .datum,
                                 
                              buchungen.zimmer
                              FROM
                                 datum INNER JOIN
                                 buchungen ON 
                              (datum.datum BETWEEN buchungen.von AND buchungen.bis)
                              WHERE
                                 datum
                              .datum BETWEEN '6.1 -13.1' 
                              Damit bekommst für alle Zimmer jeden gebuchten Tag. Machst du aus dem SELECT ein DISTINCT buchungen.zimmer hast du alle Zimmer die in dem Zeitraum irgendwie gebucht sind. Das als Subquery und du hast alle freien Zimmer.
                              Für kleine "kleine" Zeitbereiche sollte das problemlos funktionieren und auch skalieren (kombinierter index auf von ASC und bis DESC). Hässlich dürfte es werden wenn du Minuten betrachten willst und das über Jahre.

                              Kommentar


                              • #45
                                erc , vielen Dank ich teste das mal so.

                                Kommentar

                                Lädt...
                                X