Komplexe, zubuchbare Leistungen abstrahieren

[nahpets]

Zitat von Valle:

Leider sehe ich nicht, wie mit diese Datenbankstruktur beim Problem weiterhelfen soll.

Das Regelwerk steht in der Datenbank. Ändert sich eine Regel, wird der entsprechende Datensatz in der Datenbank geändert, einer hinzugefügt oder entfernt. Am Quelltext findet genau keine Änderung statt.

Der Versuch eines Beispiels:

Kunde möchte nach München
Alle Hotels... aus München suchen
Kunde möchte ein Doppelzimmer
Alle Hotels... aus München mit Doppelzimmer suchen
Kunde hat eine Preisobergrenze
Alle Hotels... aus München mit Doppelzimmer bis zur Preisobergrenze suchen
Kunde benötigt ein Kinderbett
Alle Hotels... aus München mit Doppelzimmer bis zur Preisobergrenze mit Kinderbett suchen
Kunde möchte Weinpaket
Alle Hotels... aus München mit Doppelzimmer bis zur Preisobergrenze mit Kinderbett und Weinpaket suchen

Natürlich muss jetzt nicht für jeden Schritt eine einzelne Abfrage erfolgen. Wenn die Suchmasken für alle Extras... eine Eingabeoption, Checkbox, Editfeld... enthält, kannst Du damit gezielt eine bestimmte (Teil)Menge suchen lassen, die den gewünschten Kriterien entspricht.

So kannst Du die Anzeige über beliebige Regeln einschränken lassen, bis genau die Hotels... übrigbleiben, bei denen die gewünschten Extras zubuchbar sind.

Dies läßt sich, bei entsprechendem Datenmodell und Regelwerk, bis auf die einzelnen Zimmer der Hotels runterbrechen. Für jedes Hotel, jedes Zimmer muss im Regelwerk halt stehen, was möglich ist.
Durch Abfrage der von Dir gewünschten Bedingungen im Regelwerk kannst Du per SQL auf alle Wünsche eingehen. Eine derartige Logik im Quelltext abzubilden, halte ich nicht für sinnvoll, Du wirst irgendwann mit dem Ändern und Anpassen von Regeln und Ausnahmen nicht mehr nachkommen.
Über ein sinnvolles Datenbankdesign kannst Du mit implementierungstechnisch geringen Aufwand die kompliziertesten Regelwerke abbilden.

[p80286]

@napeths

Es kommt wohl darauf an aus welcher Ecke heraus man ein Problem versucht zu lösen.

Gruß
K-H

[nahpets]

@p80286

Zitat von p80286:

@napeths

Es kommt wohl darauf an aus welcher Ecke heraus man ein Problem versucht zu lösen.

Gruß
K-H

und meine Ecke ist ganz eindeutig die Faulheit. Neudeutsch: Ökonomisches Prinzip.

Wie kann ich mit möglichst wenig dauerhaftem Aufwand möglichst viel erreichen. Und da ist meine praktische Erfahrung: Alles, von dem ich zu Beginn der Programmierung nicht ausgehen kann, dass es konstant ist und bleibt, gehört in ein Regelwerk, welches ich dynamisch pflegen kann, ohne die Software, die dieses Regelwerk nutzt, ändern zu müssen.

Im Extremfall enthält bei mir eine Datenbankanwendung nur ein SQL-Statement: Nämlich das, um die SQL-Statements aus der Datenbank zu lesen. Jedes Statement hat einen technischen Schlüssel, über den ich es im Programm erreichen kann. Dadurch kann ich Anpassungen an den Bedingungen vornehmen, ohne das Programm ändern zu müssen. Listenansichten lassen sich flexibe gestalten. Selbst bei einem Wechsel der Datenbank kann man so durch Ändern der Datenbankinhalte auf die Syntaxunterschiede der einzelnen SQL-Dialekte eingehen ohne an der Software Änderungen vornehmen zu müssen.

Man hat einmal viel, sehr viel Arbeit, aber danach ist es fast schon belanglos einfach.

[tgvoelker]

Ich würde da zwei Tabellen machen, eine mit den Artikeln (Attributfeld Hauptartikel: alleine buchbar, Zusatzartikel: nur zu Hauptartikel buchbar). Die zweite Tabelle steuert die Beziehungen: im ersten Feld Verweis auf PK für die Hauptartikel. Im zweiten Veld Verweis auf PK für die zubuchbaren Artikel. Drittes Feld Menge Zwangszubuchungen (bei Zimmer A gibt es immer ein Abendessen dazu und eine Thaimasseuse und Handentspannung), viertes Feld max. Menge optionale Zubuchungen (1 Aufenthalt Kind ==> max. 1 Beistellbett), 5. Feld (Bit) "nicht zubuchbar", 6. Feld Preis (nur, wenn Zusatzartikel D i.V. mit Hauptartikel A anders kostet, als i.V.m. Hauptartikel B).

Daran vorbei, die einzelnen Kombinationen zu hinterlegen, kommste wohl nicht.

Damit müßtest alles abbilden können.

[mjustin]

Mein Lesetipp:

Domain Driven Design: Tackling Complexity in the Heart of Software

von Eric Evans.

Das dürfte alle Fragen restlos beantworten. Nein, ich zitiere jetzt nicht die relevanten Absätze

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.

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

[mjustin]

Zitat von nahpets:

Durch Abfrage der von Dir gewünschten Bedingungen im Regelwerk kannst Du per SQL auf alle Wünsche eingehen. Eine derartige Logik im Quelltext abzubilden, halte ich nicht für sinnvoll, Du wirst irgendwann mit dem Ändern und Anpassen von Regeln und Ausnahmen nicht mehr nachkommen.
Über ein sinnvolles Datenbankdesign kannst Du mit implementierungstechnisch geringen Aufwand die kompliziertesten Regelwerke abbilden.

Zusammengefasst: "SQL > Delphi Code"

Das Ändern und Anpassen in der Datenbank ist einfacher als das ändern von Code? Es soll Unternehmen geben, in denen jede Änderung an der Datenbank eine Unterschrift der Geschäftsführung erfordert. Wird das Regelwerk nur einmal festgelegt und ändert sich nur alle Jubeljahre mal, dann mag das technisch und praktisch gehen. Das meinte ich mit "statisch" (im Sinne von "auch Glas ist eine Flüssigkeit"...).

In objektorientiertem Delphi Code, der auch problemlos durch Unit-Test abgesichert werden kann, halte ich Implementierung für deutlich flexibler. Wer mag und die Zeit hat, kann sich natürlich auch einen Generator für Tabellen und Abfragen programmieren, der in der Lage ist eine bestehende Datenbank sogar im laufenden Betrieb auf neue Regeln upzugraden