Ankündigung

Einklappen
Keine Ankündigung bisher.

[Erledigt] DB Design - Zeiräume für Preiskategorien

Einklappen

Neue Werbung 2019

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

  • [Erledigt] DB Design - Zeiräume für Preiskategorien

    Ich erstellen gerade ein ERM für ein Zimmerbuchungssystem und stehe gerade vor folgendem Problem:
    Ein Zimmer kann 2 Preiskategorien (z.B normal, erhöht) für bestimmte Zeiträume haben. Die Preise und ob ein Zimmer belegt ist sollen in einem Kalender angezeigt werden, mir geht es aber erstmal nur darum wie ich meine Tabellen am besten anlege.
    Meine Idee:

    table room{
    id (PK)
    normal price
    higher price
    ...
    }

    table room_reservation{
    id (PK)
    room_id (FK)
    start_date
    end_date
    status
    }



    In der tabelle "room" sind alle relevante daten eines zimmers sowie der Normalpreis und der erhöte Preis hinterlegt. In der Tabelle "room_reservation"
    werden für jedes zimmer zeiträume hinterlegt in denen das zimmer den erhöhten preis (status = 1) oder ob das zimmer belegt ist (status = 2). Der Zeitraum mit Normalpreis wird nicht gespeichert, da immer wenn das Zimmer nicht belegt oder nicht den erhöhten preis hat davon ausgegangen wird, dass das Zimmer zum Normalpreis verfügbar ist.

    Meine Frage: Ist das so sinnvoll, sieht jdn. Nachteile oder hat evtl. eine bessere Idee?

    Vielen Dank für eure Unterstützung/Feedback!


  • #2
    Hmm, ich würde die Preisgestaltung auf jeden Fall in eine weitere Tabelle auslagern. Die kannst Du dann auch über einen langen Zeitraum bestehen lassen und nur die Zuordung ändern:
    Code:
    Preise
    ID | Kosten | weitere Parameter
    
    Raum: 
    ID = 4711
    aktuellerPreis = Preise.SommerpreisLuxus
    Genauso könntest Du jahreszeitabhängige Automatismen umsetzen
    Code:
    Preise
    ID     | Wann    | Kosten | weitere Parameter
    Normal   Sommer
    Luxus    Sommer
    Normal   Winter    ...
    
    oder 
    
    Preise
    ID     | Ab     | Bis    | Kosten | weitere Parameter
    Normal   05-01    09-30
    Normal   10-01    04-30    ...
    --

    „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
    Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


    --

    Kommentar


    • #3
      Danke erstmal für schnelle Antwort. Ich bin mir aber nicht sicher ob das in meinem Fall Sinn macht. Ich sollte vlt. mein Projekt genauer beschreiben:
      Es geht um ein Portal, wo viele verschiedene Anbieter, überwiegend Privatpersonen aber auch Hotels, ein Zimmer zum mieten anbieten. D.h. es gibt sehr viele unterschiedliche Zimmer (>1000) mit unterschiedlichen Preisen. Außerdem sind die Zeiträume, in denen der Preis erhöt ist, von Zimmer zu Zimmer unterschiedlich und werden vom jeweiligen Anbieter festgelegt (es werden Zimmer weltweit angeboten, also summer != summer oder zum Oktoberfest erhöhen vermutlich nur die Münchner ihre Preise).

      Ich denke dein Vorschlag bezieht sich vielmehr auf ein Buchungssystem von einem einzigen oder wenigen Hotels. Da habe ich mich nicht klar genug ausgedrückt.
      Oder habe ich deinen Vorschlag nicht richtig verstanden?

      In meinem Ansatz (s.o) sehe ich vor allem das Problem, dass ich mich auf eine bestimmte Anzahl von Preiskategorien festlegen muss und diesbezgl. völlig unflexibel bin.

      Kommentar


      • #4
        Nein, das hast Du genau richtig verstanden. Das ist natürlich eine andere Voraussetzung. Trozdem kannst Du natürlich Preiskategorien in einer separaten Tabelle auslagern, so dass Du pro Anbieter bspw. 3 Datensätze dort erlaubst (PHP-seitig). Du bist dann trotzdem aber so flexibel, die maximalzahl anzupassen, selbst bestimmten Kunden Sonderkonditionen einräumen zu können etc.

        Aus technischer Sicht ist der Vorteil, die Datenbankstrukturen nicht ändern zu müssen. Damit wird die PHP-Seite auch verbindlicher, weil Du dort keine Auswertungen zusätzlicher Felder etc. implementieren musst.
        --

        „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
        Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


        --

        Kommentar


        • #5
          Alles klar. Die Preiskategorien auslager ist natürlich sinnvoll. Dann würde ich das ganze so aufbauen:

          Code:
          room
          id | weiter parameter
          
          
          room_price
          id | room_id (FK) | preiskategorie | preis | währung
          
          
          room_pricelist
          id | room_price_id (FK) | start_date | end_date
          In room_price erlaube ich php-seitig nur eine bestimmte anzahl von Einträgen pro Zimmer und kann auch nur bestimmte Auswahlmöglichkeiten für Preiskategorien festlegen. In room_pricelist speicher ich ab in welchen Zeiträumen ein Zimmer welchen Preis hat. Hier muss ich natürlich auch php-seitig regeln dass einem Zimmer nur Preiskategorien zugeorndet werden können, die auch für das zimmer definiert wurden. Sonderkondition für bestimmte Anbieter kann ich ja auch über die Relation zwischen den Anbieter und den Zimmern (hier nicht dargestellt) umsetzen ohne die Datenbankstruktur zu ändern.

          Weiteres feedback ist gerne trotzdem noch erwünscht. Arbeite gerade alleine an dem Projekt und man übersieht doch immer gerne mal was...

          Kommentar

          Lädt...
          X