@mjustin
Eine datenbankzentrierte Lösung würde ich für ein komplexes, hoch flexibles Regelwerk erst mal nicht in die engere Wahl ziehen - es sei denn, es ist ein klar überschaubares Regelwerk, das sich so gut wie nie ändern wird (zum Beispiel weil es auf Naturgesetzen basiert), und performant umgesetzt werden kann.
Dem stimme ich nicht zu. Meiner Meinung nach kann man nirgendwo Regeln einfacher und pflegbarer ablegen, als in einer Datenbank.
Also für mich hört sich Valles Beschreibung so an, als ob die Regeln beliebig kompliziert werden könnten. Sicherlich kann man das mit Ach und Krach auf eine Datenbank abbilden, aber ich glaube, das wird irgendwann sehr unübersichtlich und schlecht wartbar. Wenn man solche Regeln hat wie „wenn das und das und das, aber nur wenn nicht dies und jenes, und nur bei mehr als 3 Wochen und nur wenn ein Freitag dazwischen ist“, dann ist das kein Datensatz mehr sondern Programmcode.
Natürlich kann man das nicht in "einem" Datensatz ablegen, dass wäre auch das denkbar schlechteste Datenbankdesign. Diese Regeln sind eine klassische 1:n-Beziehung.
Eine Tabelle mit den Ferienhäusern. (Hier stehen alle Freienhäuser drinne und die Eigenschaften des Ferienhauses, die unveränderlich sind. Z. B.: Anzahl der Zimmer.)
Eine Tabelle in der steht, was es alles gibt. Also alles, was irgendwie, irgendwo gebucht werden kann. (nicht pro Ferienhaus, sondern überhaupt!)
Eine Tabelle, die die Beziehung zwischen den Ferienhäusern und dem, was es alles gibt auflöst.
Also für jedes Ferienhaus 1 bis n-Sätze, entsprechend dem, was es gibt. Hier kann dann auch für jede Leistung zum Ferienhaus festgehalten werden, ob inklusive oder zubuchbar. Das ist über boolsche Werte lösbar. Den Preis kann man auch hier ablegen.
Ferienhaus 1 - Zimmerservice - incl. - 0,00€
Ferienhaus 1 - Einkaufsservice - buchbar - 7,50€
Ferienhaus 2 - Zimmerservice - buchbar - 12,50€
Ferienhaus 3 - Zimmerservice - incl. - 0,00€
Ferienhaus 3 - Einkaufsservice - incl. - 0,00€
...
Dann wird eine Tabelle benötigt, in der vermerkt ist, von wann bis wann welches Ferienhaus "vergeben" ist. Auch hier haben wir wieder eine 1:n-Beziehung zur Tabelle der Ferienhäuser.
Ferienhaus 1 - 25.05.2013 - 28.05.2013 -
Ferienhaus 1 - 08.06.2013 - 24.06.2013
Ferienhaus 3 - 21.05.2013 - 21.06.2013 -
Ferienhaus 3 - 25.06.2013 - 08.07.2013 -
...
Ich würde das als Plugin realisieren. Gerade bei einer Skriptsprache geht das doch super... dann könnte man bestimmte „Templates“ erstellen für z.B. Einkaufsservice (das erledigt natürlich im besten Fall ein Programmierer), und dann kann man in der Adminoberfläche für jeden Datensatz (also das wäre z.B. ein Hotel oder Zimmer, weiß ja nicht wie das genau bei euch abläuft) Plugins aktivieren und deaktivieren und ggf. konfigurieren (das sollte dann jeder bedienen können).
Heißt das pro Regel ein Plugin? Und wenn man pro Regel ein Plugin vom Admin konfigurieren kann, warum kann man das dann nicht direkt für die Regel? Beides ist letztlich in der Datenbank "nur" ein ja/nein-Schalter.
Aus Datenbankinhalten kann man dynamisch die Webseiten erstellen, die dann nur noch das Anbieten, was "fest geregelt" ist und das, was zubuchbar ist.
Mag sein, dass das Regelwerk komplex ist, aber so komplex, das es nicht über ein normalisiertes Datenmodell abbildbar ist, ist es mit Sicherheit nicht.
@Valle
Zitat von
Valle:
Unsere Kunden suchen also kein Hotel mit bestimmten Features, sondern haben bereits ein Ferienhaus ausgesucht und können wahlweise Dinge hinzubuchen oder Leistungen sehen, die sowieso inklusive sind. Kann man, meiner Meinung nach, in der Datenbank äußerst schwer nachbilden.
Sorry, aber das klingt für mich eher wie ein triviales Problem. Würde mich schwer wundern, wenn man das nicht mit drei Datenbanktabellen, wie oben angedeutet, abbilden könnte.
Versuch bitte einmal einige oder alle der Regeln in eine Tabelle (Excel oder so) zu schreiben und dann dort Struktur reinzubringen. Nach Deiner Beschreibung benötigst Du doch "nur" zu einem festgelegten Ferienhaus alle die Dinge, die man sowieso mitgebucht hat und alle die Dinge, die hinzugebucht werden können. Es wird hier meiner Meinung nach nur eine Tabelle gebraucht, die die Verbindung zwischen den Ferienhäusern und den "Dingen" herstellt. In dieser Verbindung muss halt nur mit dabeistehen, ob fest dabei oder zubuchbar und ggfls. der Preis.
Kann man sich die Webseiten mal anschauen? (Live oder Screenshot) Eventuell ist es dann einfacher zu verstehen, warum es Dir so schwierig erscheint. Dann ist eventuell ja eine "zielgerichtetere" Hilfe möglich.
Eins muss allerdings klar sein: Wer bei einem derartigen Regelwerk versucht, diese Regeln pro Ferienhaus in einer Datenbankzeile abzulegen, der wird scheitern.
Zuerst müssen die Daten "vernünftig" modelliert werden. In der Regel schrumpft damit das Problem von alleine, weil man durch die Modellierung überhaupt erst erkennt, ob es eine Komplexität gibt, und wenn ja, wie hoch sie ist.
Gibt es z. B. Abhängigkeiten zwischen den Dingen, die incl. sind und den zubuchbaren Dingen?
Kann man einen Mietwagen z. B. nur dann buchen, wenn man auch den Flug gebucht hat?
Lassen sich die Regeln als Baum darstellen und wie weit ist der dann verzweigt?
Nach der Beschreibung wäre für mich jedes Ferienhaus erstmal ein Baumstamm und jedes Ding ein Zweig. Die Zweige können optional sein. Eine tiefere Verschachtelung gibt die vorliegende Beschreibung nicht her.
Gib' bitte mal noch ein bisserl mehr Input, vielleicht bin ich ja auch auf dem Holzweg. Bisher kann ich keine hohe Komplexität erkennen, sondern nur, dass es viele Regeln (besser Dinge) gibt, denn die Dinge scheinen ja keine Regel zu sein, sondern feste oder wahlweise Optionen.