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

  • Datenbank Design für eine Buchungsseite ( Ferienwohnung vermieten)

    Hallo,
    ich habe mir zu Übungszwecken vorgenommen eine Reise Buchungsseite auf die Beine zu stellen.
    Mache mir derzeit Gedanken wie ich am besten alles in der DB unterbringe.

    Ich muss dazu sagen ich bin kein Profi und wäre sehr froh wenn der ein oder andere gute Tipp dabei wäre von euch

    Das Preismodell soll wie folgt aussehen:

    Saison Preise:

    November (01.11 - 30.11)

    Preis pro tag Standard: 20 €
    Preis für einen Monat: 450 €

    Dazu kommt dann noch:

    Pro Gast 10 € für Strom oder Handtücher sonst was
    Endreinigung: 100 €

    Wie könnte da am besten mein Datenbank Design aussehen?

    Ich habe mir folgendes bis jetzt gedacht, sicherlich habt ihr noch einen besseren Vorschlag

    Tabelle: rooms


    Sieht das soweit okay aus oder würdet ihr für die Preise eine eigene Tabelle anlegen?

    Wie kann ich das am besten mit den Saison Preisen realisieren?

    Vielleicht könnt ihr mir dazu mal einen Denkanstoß geben, stehe gerade richtig auf den Schlauch wie ich am besten die DB aufbauen soll.



  • #2
    Hallo!

    Vorweg: Bitte keine Screenshots, besser die SQL CREATE Statements als Code posten.

    Das ist gar nicht so trivial. Ich finde deine Fragen kann man auf die Schnelle nicht mit Ja, Nein beantworten.

    Gegenfrage.. Dazu gibt es schon einiges im www.. Hast du dir da schon bestehende Lösungen angesehen wie die das machen?
    Debugging: Finde DEINE Fehler selbst! | Gegen Probleme beim E-Mail-Versand | Sicheres Passwort-Hashing | Includes niemals ohne __DIR__
    PHP.de Wissenssammlung | Kein Support per PN

    Kommentar


    • #3
      Hallo hausi,
      sorry für den Screenshot, werde nächstes mal die SQL Statements als Code posten.
      Ja habe gegoogelt, bin aber wie es aussieht zu doof dafür, konnte nichts passendes finden.

      Werde sofort nochmal versuchen was zu finden!

      // Edit:

      Okay, habe nun einiges gefunden, werde mich mal da durchlesen um Inspirationen zu erhalten

      Kommentar


      • #4
        Ich sehe nicht mal ein Bild dazu? Wurde das etwa obendrein gelöscht?

        Kommentar


        • #5
          So weit bin ich bis jetzt, zumindest Gedanklich.....

          Code:
          -- phpMyAdmin SQL Dump
          -- version 4.9.0.1
          -- https://www.phpmyadmin.net/
          --
          -- Host: 127.0.0.1
          -- Erstellungszeit: 12. Nov 2019 um 17:32
          -- Server-Version: 10.4.6-MariaDB
          -- PHP-Version: 7.3.9
          
          SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";
          SET AUTOCOMMIT = 0;
          START TRANSACTION;
          SET time_zone = "+00:00";
          
          
          /*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
          /*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
          /*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
          /*!40101 SET NAMES utf8mb4 */;
          
          --
          -- Datenbank: `bsystem`
          --
          
          -- --------------------------------------------------------
          
          --
          -- Tabellenstruktur für Tabelle `booking`
          --
          
          CREATE TABLE `booking` (
            `id` int(11) NOT NULL,
            `room_id` int(11) NOT NULL,
            `surname` varchar(255) NOT NULL,
            `lastname` varchar(255) NOT NULL,
            `email` varchar(255) NOT NULL,
            `phone` varchar(20) NOT NULL,
            `address` varchar(255) NOT NULL,
            `city` varchar(255) NOT NULL,
            `postcode` int(6) NOT NULL,
            `request` text NOT NULL,
            `start_date` date NOT NULL,
            `end_date` date NOT NULL,
            `total_price` decimal(10,0) NOT NULL,
            `deposit_price` decimal(10,0) NOT NULL
          ) ENGINE=InnoDB DEFAULT CHARSET=latin1;
          
          -- --------------------------------------------------------
          
          --
          -- Tabellenstruktur für Tabelle `rooms`
          --
          
          CREATE TABLE `rooms` (
            `id` int(11) NOT NULL,
            `room_title` varchar(255) NOT NULL,
            `room_desc` text NOT NULL,
            `room_max_guests` tinyint(1) NOT NULL,
            `min_book_days` int(3) NOT NULL,
            `price_day` decimal(10,0) NOT NULL,
            `price_month` decimal(10,0) NOT NULL
          ) ENGINE=InnoDB DEFAULT CHARSET=latin1;
          
          --
          -- Indizes der exportierten Tabellen
          --
          
          --
          -- Indizes für die Tabelle `booking`
          --
          ALTER TABLE `booking`
            ADD PRIMARY KEY (`id`);
          
          --
          -- Indizes für die Tabelle `rooms`
          --
          ALTER TABLE `rooms`
            ADD PRIMARY KEY (`id`);
          
          --
          -- AUTO_INCREMENT für exportierte Tabellen
          --
          
          --
          -- AUTO_INCREMENT für Tabelle `booking`
          --
          ALTER TABLE `booking`
            MODIFY `id` int(11) NOT NULL AUTO_INCREMENT;
          
          --
          -- AUTO_INCREMENT für Tabelle `rooms`
          --
          ALTER TABLE `rooms`
            MODIFY `id` int(11) NOT NULL AUTO_INCREMENT;
          COMMIT;
          
          /*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
          /*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
          /*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
          Ich denke soweit so gut, zumindest für meinen jetzigen Skill.

          Wie kann ich es aber das mit den Saison preise realisieren in der DB

          Das es im Januar günstiger ist als im August

          Bucht jemand vom 01.01. - 30.01 = 450 €
          bucht jemand im August: 01.08. - 30.08 = 800 €

          Dafür müsste ich wahrscheinlich eine neue Tabelle erstellen? Und das alles miteinander verknüpfen?

          Oder bin ich ganz auf dem falschen Weg?

          Kommentar


          • #6
            In PostgreSQL hättest Du die Möglichkeit, DATERANGES zu verwenden. Die wären praktisch für die Zimmervermietung, denn sie bieten auch die Möglichkeit, via Constraint eine Doppelbelegung zu vermeiden. Deine Saison-Preise könntest Du ebenso speichern, und mit einfachen Abfragen ermitteln, welche Buchungen zu welchen Tagen mit welchen Preisen zu versehen sind.

            Und ja: ein immer wider gern genommener Fehler ist die Verwendung von Integer für PLZ.
            PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

            Kommentar


            • #7
              Zitat von akretschmer Beitrag anzeigen
              In PostgreSQL hättest Du die Möglichkeit, DATERANGES zu verwenden. Die wären praktisch für die Zimmervermietung, denn sie bieten auch die Möglichkeit, via Constraint eine Doppelbelegung zu vermeiden. Deine Saison-Preise könntest Du ebenso speichern, und mit einfachen Abfragen ermitteln, welche Buchungen zu welchen Tagen mit welchen Preisen zu versehen sind.

              Und ja: ein immer wider gern genommener Fehler ist die Verwendung von Integer für PLZ.
              Okay, das habe ich schon immer so gehandhabt mit der PLZ, dann habe ich es wohl schon immer falsch gemacht, was wäre denn der bessere Datentyp?
              Habe mich noch nie mit PostgreSQL beschäfigt, danke für den Tipp werde mal mich da etwas einlesen

              Kommentar


              • #8
                Zitat von LordMustang Beitrag anzeigen

                Okay, das habe ich schon immer so gehandhabt mit der PLZ, dann habe ich es wohl schon immer falsch gemacht, was wäre denn der bessere Datentyp?
                Probiere mal eine mit 0 beginnende PLZ als INT zu speichern.

                Habe mich noch nie mit PostgreSQL beschäfigt, danke für den Tipp werde mal mich da etwas einlesen
                Lohnt sich, glaube mir
                PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

                Kommentar


                • #9
                  Zitat von LordMustang Beitrag anzeigen

                  Okay, das habe ich schon immer so gehandhabt mit der PLZ, dann habe ich es wohl schon immer falsch gemacht, was wäre denn der bessere Datentyp?
                  Habe mich noch nie mit PostgreSQL beschäfigt, danke für den Tipp werde mal mich da etwas einlesen
                  Zitat von akretschmer Beitrag anzeigen

                  Probiere mal eine mit 0 beginnende PLZ als INT zu speichern.



                  Lohnt sich, glaube mir
                  Wenn ich mir so manches hier anschaue, habe ich da meine Zweifel.

                  Aber und LordMustang: Ich denke, du bist gut beraten, erstmal SQL zu erlernen, und das geht nachweislich mit einem angeblich "steinzeitlichen" RDBMS wie MySQL wesentlich besser. Vorher aber mußt du in Puncto Datenmodell und DB-Design noch was lernen. Habe mir dazu mal deine DB installiert und angeschaut:
                  1. Du hast zu wenige Tabellen (!?!), weil deine Tabellen noch nicht in Normalform vorliegen. Du müsstest sie also erstmal normalisieren.
                  2. Meine Empfehlung: Da davon auszugehen ist, daß du über Normalisierung bis jetzt nichts oder wenig weißt und jedenfalls das noch nicht verstanden hast, rate ich dir, folgendermaßen vorzugehen:
                    Welche "Objekte" (leider muß man in diesem Fall auch von Menschen als Objekte sprechen) habe ich? Objekte können sein: Personen, Gegenstände, Sachverhalte. Bei dir z.B. Kunden, Räume, Buchungen. Erläuterung zu Sachverhalten: Damit sind Handlungen (Kunde bucht Zimmer) wie auch solche Sachverhalte gemeint, die eine Struktur angeben (z.B. im Unternehmen: Abteilung hat Mitarbeiter. Ich komme darauf unter 4. zurück.
                    Lege den Schwerpunkt erstmal auf Personen und Gegenstände, da fehlen z.B. noch völlig die Kunden, also eigene Tabelle tbl_kunde oder einfach kunde! Hier bitte erstmal mit beginnen, bevor du mit allem anderen weitermachst! Mach das ganze erstmal zeichnerisch mit Kästchen pro Tabelle, die können so aussehen:
                    tbl_kunde
                    KundeID

                    Nachname
                    ...
                    außen "Käschtle drum". Die einzelnen Objekte kannst du erstmal so auf dem Papier anordnen, daß die, die was miteinander zu tun haben, näher beieinander stehen, aber immer noch Platz für zusätzliche Kästen = Tabellen dazwischen bleibt.
                  3. Als nächstes geht es darum, wie deine Objekte "miteinander zu tun haben" (ich vermeide bewußt den Begriff "Beziehungen"). Dabei wird dir vor allem eines auffallen:
                  4. Einige Sachverhalte = Vorgänge werden möglicherweise bei dir noch nicht abgebildet. Buchungen hast du ("booking" - warum Englisch?), aber was ist mit der konkreten Nutzung der Zimmer. Wir sind also bei den Sachverhalten, auch die "verdienen" eigene Tabellen. Bilde dazu jeweils Sätze aus Subjekt, Prädikat, Objekt (SPO-Prinzip): Kunde (tbl_kunde) bucht (tbl_buchung = "booking") Zimmer (tbl_zimmer = "rooms"). Nur der Vorgang bzw. Sachverhalt (=Prädikat, konkret: ein Verb wie buchen, bestellen usw., aber auch "haben", z.B. "Abteilung hat Mitarbeiter") wird durch die Tabelle "tbl_buchung" abgebildet. "Kunde Maier bucht am 11.11.2019 das Zimmer 13 für 3 Nächte" schlägt sich also in der Tabelle tbl_buchung als Datensatz mit
                    HTML-Code:
                    <p style = "font-family: Courier New, Courier New, serif;">+-----------+-----------+-----------+-------------+<br>
                    	| KundeID_FK|ZimmerID_FK| BuDat&nbsp;&nbsp;&nbsp;&nbsp; |AnzahlNaechte|<br>
                    	+-----------+-----------+-----------+-------------+<br>
                    	   | ...<br>
                    	   |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1 |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;13 |11.11.2019 | &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3 |<br>
                    	   | ...</p>
                    (sorry, wußte nicht, wie ich das hier reinbringe, deshalb html).
                  5. Bei diesen "SPO-Sätzen" mußt du noch schauen, ob es sich um 1:n oder n:m-Beziehungen (ein DS links hat mehrere DS rechts und umgekehrt) handelt. Wenn nicht, braucht es im Regelfall keine neue Tabelle, alle rel. Informationen wandern dann in die n-Tabelle (Fremdschlüssel auf die übergeordn. Tab., z.B. "AbteilungID_FK" usw.). Du must aber sehr genau hinsehen, oft übersieht man n:m-Beziehungen.
                  6. Am Ende verbindest du die Tabellen mit Linien zwischen den Tabellen, über die jeweiligen PK und FK.
                  Wenn du damit fertig bist, melde dich hier wieder.

                  Kommentar


                  • #10
                    Zitat von marie123 Beitrag anzeigen
                    ... erstmal SQL zu erlernen, und das geht nachweislich mit einem angeblich "steinzeitlichen" RDBMS wie MySQL wesentlich besser.
                    Oh oh. MySQL enthält diverse Fehler, die es gerade als Lernsystem nicht geeignet machen.
                    PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

                    Kommentar


                    • #11
                      Marie123 scheint Alf2016 zu sein, zumindest sind Beiträge und Schreibstil sehr ähnlich und das vermittelte Wissen auch. Da muss man sich also nicht wundern.

                      Kommentar


                      • #12
                        Zitat von akretschmer Beitrag anzeigen

                        Oh oh. MySQL enthält diverse Fehler, die es gerade als Lernsystem nicht geeignet machen.
                        Z.B. welche (Fehler)?

                        Kommentar


                        • #13
                          Zitat von marie123 Beitrag anzeigen
                          Z.B. welche (Fehler)?
                          MySQL erlaubt z.B.: select a,b,c, max(d), avg(e) from table group by a; und liefert statt einer Fehlermeldung ein falsches Resultat. Mehr hier: https://www.youtube.com/watch?v=emgJtr9tIME&t=2s
                          PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

                          Kommentar


                          • #14
                            Aber das ist doch in aktuellen Versionen nicht mehr so... hatten wir das nicht schonmal?
                            Competence-Center -> Enjoy the Informatrix
                            PHProcks!Einsteiger freundliche TutorialsPreComposed Packages

                            Kommentar


                            • #15
                              Zitat von akretschmer Beitrag anzeigen

                              MySQL erlaubt z.B.: select a,b,c, max(d), avg(e) from table group by a; und liefert statt einer Fehlermeldung ein falsches Resultat. Mehr hier: https://www.youtube.com/watch?v=emgJtr9tIME&t=2s
                              Das ist ein altes Thema, das auch hier mal wieder von einigen nicht verstanden wurde. Kurz erklärt:
                              Es gibt Datenbanksysteme, die sehr strikt mit dem SQL-Code umgehen und damit u.a. Fehler der Entwickler vermeiden, aber diese auch unnötig einschränken. Und dann gibt es solche, die "liberaler" damit verfahren und es dem Entwickler überlassen, Fehler dabei zu vermeiden.

                              Mit "richtig" oder "falsch" hat das aber überhaupt nichts zu tun - ich würde eher sagen: mit Bevormundung oder Unterlassung der selbigen.

                              Das Problem: Oft möchte ein Entwickler in der Feldliste Spalten haben, die in der Gruppe nicht aufgeführt wurden und auch nicht aggregiert werden (zu den Begriffen: Es gibt nicht "aggregierte" und "gruppierte" Spalten, was aber eine unglückliche Wortwahl ist, weil der gesamte "Vorgang" eine Aggregation ist, die ohne Summierung, Abzählen, Durchschnitt - was auch immer die Aggregatfunktion tut -, aber eben auch nicht ohne Gruppierung auskommt. Die Aggregatfunktion aggregiert die Werte einer Spalte über alle (wenn es Sinn machen soll, >1) Werte, die die jeweilige, die Gruppe konstituierende Merkmalskombination der gruppierten Spalten aufweist).

                              Dabei können zwei Fälle unterschieden werden:
                              • Die Spalten, die er zusätzlich zu den gruppierten in die Feldliste (SELECT Spalte1, Spalte2, ...) aufnehmen möchte, sind funktional 1:1 von anderen Spalten abhängig oder diesen "hierarchisch übergeordnet, z.B. AbteilungID_FK gegenüber MitarbeiterID. In diesem Fall erbringt die zusätzliche Aufnahme in die Feldliste keine unsinnige Ausgabe.
                              • Die zusätzlichen Spalten sind - wie im vorliegenden Fall die Spalte 'kunde' - den anderen Spalten, die bis dahin in der GROUP BY-Gruppe standen, hierarchisch untergeordnet und würde damit zu einer "Verfeinerung" (=Vermehrung der gebildeten Gruppen) der Gruppenbildung führen, weshalb sie dort unerwünscht sind. Da sie bei der Feldliste aber "erwünscht" sind (schließlich will man ja wissen, wer zur betr. "Ware" die Auktion gewonnen hat und nicht nur, was das höchste Angebot ist), besteht die "Versuchung", den kurzen Weg zu gehen und sie dort aufzunehmen. Das wäre aber aus den von mir in #34 genannten Gründen falsch, so würde bspw. Maxi mit einem höchstgebot von 182 angezeigt, obwohl dieses von Kind Ich kam. In diesem Fall ist der geschachtelte Select wie von Meister1900 vorgeschlagen unausweichlich.
                              Wie gesagt, mit "Fehlern von MySQL" hat das überhaupt nichts zu tun. Es bleibt dabei: MySQL ist zum Lernen besser geeignet als z.B. Postgre.

                              Kommentar

                              Lädt...
                              X