Ich wurde vor kurzem gebeten, eine Interviewfrage zu einem hypothetischen webbasierten Buchungssystem zu stellen und wie ich das Datenbankschema so gestalten würde, dass Duplikate minimiert und die Flexibilität maximiert wird.
Der Anwendungsfall ist, dass ein Administrator die Verfügbarkeit einer Eigenschaft in das System eingeben würde. Es könnte mehrere Zeiträume festgelegt werden. Zum Beispiel vom 1. April 2009 bis zum 14. April 2009 und vom 3. Juli 2009 bis zum 21. Juli 2009.
Ein Nutzer kann dann nur in den zur Verfügung gestellten Zeiträumen eine Buchung in gleichen oder kürzeren Zeiträumen vornehmen.
Wie würden Sie diese Informationen in einer Datenbank speichern?
Würdest du etwas so einfaches (wirklich vereinfachtes) als verwenden?
%Vor%Könnten Sie dann einfach eine Webseite erstellen, die einen Verfügbarkeitskalender mit ausgebuchten Stunden anzeigt? Wäre es einfach, Berichte aus diesem Datenbankschema zu erstellen? Ist es so einfach wie es scheint?
Es kann einfacher sein, mit einer einzigen Tabelle sowohl für die Verfügbarkeit als auch für die Buchung zu arbeiten, mit einer Granularität von 1 Tag:
%Vor%Der Spaltenstatus würde (mindestens) die folgenden 2 Werte haben:
Eingeben einer Verfügbarkeitszeit z.B. Vom 1. bis zum 14. April würde (die Anwendung) 14 Zeilen in property_date mit dem Status "Available" einfügen. (Für den Benutzer sollte es wie eine einzelne Aktion erscheinen.)
Wenn Sie die Immobilie für den Zeitraum vom 3. bis 11. April buchen, müssen Sie prüfen, ob für jeden Tag eine Zeile "Verfügbar" vorhanden ist, und den Status in "Gebucht" ändern.
Dieses Modell mag etwas "ausführlich" erscheinen, hat aber einige Vorteile:
NB Wenn "verfügbar" der gebräuchlichste Status einer Eigenschaft ist, ist es möglicherweise besser, die Logik umzukehren, so dass der Status "Nicht verfügbar" vorhanden ist und das Fehlen einer Zeile für ein Datum bedeutet, dass sie verfügbar ist.
Tags und Links database database-design schema