Komplexe, zubuchbare Leistungen abstrahieren

[nahpets]

@mjustin

Zitat von 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. Und ich habe schon mit Regelwerken gearbeitet, die ich zum Zeitpunkt der Programmierung noch nicht einmal kannte. Definiert war nur, wie die Regeln in der Datenbank abzulegen sind. Und die Menge der Regeländerungen in diesen Systemen war exorbitant hoch, vierteljährliches Umkrempeln von mehr als 50% der Regeln. Die Software läuft nunmehr seit über 10 Jahren unverändert und immernoch hoch performant.

Zitat von mjustin:

es sei denn, es ist ein klar überschaubares Regelwerk, das sich so gut wie nie ändern wird (zum Beispiel weil es auf Naturgesetzen basiert),

Wenn es statisch ist und ich eh nie wieder dran muss, dann brauche ich keine Datenbank, dass kann man dann auch fest verdrahtet implementieren. Für keine Flexibilität, brauche ich keine Flexibilität, die mir eine Datenbank liefert.

[Namenloser]

Zitat von nahpets:

@mjustin

Zitat von 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.

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).

Z.B. Hotel X bietet Einkaufsservice an, dann fügt man das Einkaufsservice-Plugin hinzu und stellt noch den Preis ein. Hotel Y bietet keinen Einkaufsservice an, dann lässt man das Plugin dort deaktiviert.

Was besseres fällt mir nicht ein, wenn sich in die Regeln wirklich gar kein System hineinbringen lässt...

[Valle]

Hallo!

Vielen Dank für die vielen Antworten!

Um mal auf nahpets Vorstellung einzugehen. Ich kann mir leider beim besten Willen und denkbar größtem Aufwand nicht vorstellen, wie ich damit weiter komme. Ich vermute stark, dass ich mein Problem nicht richig erklärt habe. Unsere Kunden suchen auf unserer Webseite ein Ferienhaus aus, welches sie buchen möchten. Sie geben online oder telefonisch an, wie viele Leute sie sind und wann sie dort hin reisen wollen. Anschließend erhalten sie Zugang zum Kundenlogin.

In diesem Kundenlogin steht nun ihre Buchung, mit festem Zeitraum und Objekt. Hier tragen die Kunden Teilnehmer ein, mieten einen Mietwagen oder buchen einen Flug. Des Weiteren soll es jetzt die Möglichkeit geben, diese ganzen Zusatz-Features optional hinzu buchen zu können. Außerdem gibt es Inklusivleistungen, die in der Zusammenfassung in jedem Fall angezeigt werden müssen. Dass eine Sonnenliege in einem bestimmten Ferienhaus inklusive ist dürfen die Kunden sich nicht aussuchen.

So, und hier greift das Problem. Ich muss dem Kunden zeigen, was möglich ist. Außerdem muss er am Ende natürlich einen Preis sehen. Und genau bei den zwei Sachen greift eine sehr komplexe und schwer durchschaubare Logik. Eine große Menge an verschachtelten Ifs und Elses. Und das nur für das wenige und vergleichsweise einfache Zeug dass es bisher dazu zu buchen gibt. Die richtigen Extas kommen ja erst jetzt.

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.

@WM_CLOSE: Es besteht die Möglichkeit, Code in der Datenbank abzulegen. Lua brauchen wir nichtmal, da wir ja mit Python arbeiten. Nicht alle unserer Mitarbeiter können Python, aber wir sind eine kleine Firma und der Chef und die IT kriegen das hin. Im Zweifel kann man es lernen oder delegieren. Es ist wirklich ein einfacher Weg, da er flexibel ist und viel Arbeit spart. Ich könnte mir hier mal genaueres überlegen.

@tgvoelker: Wie bilde ich ab, dass es bei Ferienwohnung X alle 3 Tage eine Zwischenreinigung gibt, aber erst ab 10-tägiger Buchung? Oder dass Freitag das Abendessen inklusive ist, es aber Mittwoch und Montag für 14€ p.P. und 9€ pro Kind zubuchbar ist?

@mjustin: Auf lange Sicht bestimmt eine gute Idee. Aber unser Zeitplan ist eng und Bücher lesen ist leider so gar nicht meine Stärke.

@NamenLozer: Du verstehst mich. Deine Plugin-Idee klingt recht gut. Ich denke auch, dass das komplizierte Regelwerk eigentlich ja Programmierung ist. Mal überlegen wie man das umsetzen könnte.

Danke für eure große Mühe und Verzeihung falls ich mich etwas unklar ausdrücken sollte!

Liebe Grüße,
Valentin

[nahpets]

Zitat von NamenLozer:

Zitat von nahpets:

@mjustin

Zitat von 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 -
...

Zitat von NamenLozer:

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.

[Namenloser]

Zitat von nahpets:

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€

So ähnlich meine ich das im Prinzip auch, nur wäre bei mir noch Programmcode an die einzelnen Zubuchoptionen geknüpft. Und damit es nicht völlig aus dem Ruder läuft, würde ich dann die Optionen etwas generalisieren und durch Parameter konfigurierbar machen.

Bei mir wäre das z.B. so:

1. Tabelle: Plugins (PluginId, Programmcode)
2. Tabelle: Ferienhäuser (HausId)
3. Tabelle: Plugins-Ferienhäuser (HausId, PluginId)
4. Tabelle: PluginParameter (HausId, PluginId, ParameterName, ParameterWert)

Dann kann man z.B. pro Ferienhaus ein Kinderbett-Plugin aktivieren. In der Admin-Oberfläche kann man pro Haus den Parameter des Plugins einstellen, der angibt, wie viele Kinderbetten maximal dort zugebucht werden können, und was es kostet. Die Programmlogik vom Plugin checkt dann aber für den Endbenutzer auch noch, ob überhaupt Kinder mitfahren, und wenn ja wie viele.

Oder Zimmer-Reinigungs-Plugin, da stellt man ein, welche Putz-Optionen es gibt – alle 10 Tage = 0€, alle 2 Tage = X €, jeden Tag = Y €. Aber wenn der Kunde nur für zwei Tage bucht, dann kann die Plugin-Logik dafür sorgen, dass nur die letzte Option dem Endkunden angezeigt wird, denn die anderen beiden wären ja sinnlos.