Komplexe, zubuchbare Leistungen abstrahieren

[Valle]

Hi DPler,

im Momement arbeite ich an einem neuen Kundenlogin für das Reisevermittlungsunternehmen für das ich arbeite. Dabei stoße ich auf ein Problem, welches einigen von euch sicher schonmal begegnet ist.

Undzwar soll es dem Kunden bei einer Buchung in Zukunft möglich sein, diverse zusätzliche Leistungen online mit einbuchen zu können. Bisher wurden diese Sachen unter hohem Aufwand telefonisch erledigt. Unter zusätzlichen Leistungen verstehen wir Sachen wie Einkaufs-Service, Zwischenreinigungen, Weinpaket, Abendessen, Hochstühle für Babies, Hunde, usw.

Leider ist die Logik dahinter aber gar nicht so einfach. Abendessen beispwielsweise gibt es nur auf einigen Objekten, nur an bestimmten Wochentagen und kostet für Kinder und Erwachsene einen anderen Preis. Zwischenreinigungen sind meist inklusive (Preis = 0), es gibt sie aber unterschiedlich oft je nach Objekt. Oft wird erst zwischengereinigt, wenn die Buchung länger als 10 Tage dauert. Zusätzliche Zwischenreinigungen sollen aber gegen Aufpreis auch möglich sein. Aufbettungen können natürlich nur so viele gebucht werden wie vorhanden sind und wie Teilnehmer in der Buchung eingetragen sind. Fünf Baby-Betten bei nur einem Teilnehmer vom Typ Baby ergeben wenig Sinn.

Ich denke man sieht worauf ich hinaus will.

Wie setzt man sowas um? Muss man es hardcoden? Oder fallen euch schönere Alternativen ein? Hoffe ihr habt ein paar tolle Ideen.

Liebe Grüße,
Valentin

(PS.: Datenbank ist MySQL, programmiert wird in Python)

[p80286]

Du hast doch eigentlich schon alles formuliert.
Du solltest eine DB haben mit

Table Objekt - anzahl zimmer in Kategorie
Table Zimmerkategorie - Einbett zweibett balkon extrareinigung max 5betten zustellen usw.

ohne Frage kann man die Zimmerkategorie auch noch auf weitere Tabellen aufteilen, kommt darauf ann wofür es gebraucht wird und wie flexibel das alles sein soll.

dann baust Du Dir eine

Table ObjektZimmerkatLink Table in der definiert ist, was in einem Objekt an Zimmerkategorien möglich ist.

ggf. brauchst noch eine ZwischenTabelle einstern,zweistern superduperzimmer, in der definiert ist welches Objekt welchen Zimmertyp mit welchen Zusatzleistungen hat.

Nur mal so grob umrissen.

In den meisten Fällen erledigen sich diese Fragen wenn a dann b wenn c dann e und nicht b sondern..... durch ein ordentliches DB-Design.

Gruß
K-H

[Der schöne Günther]

Ich hätte erst einmal gar nicht in Tabellen gedacht, sondern als erstes schrie das geradezu nach "Decorator Pattern".

Schau mal hier, wenn das mal keine anschaulich erklärenden Grafiken sind weiß ich auch nicht.

[Valle]

Erstmal Danke für deine Antwort.

Leider sehe ich nicht, wie mit diese Datenbankstruktur beim Problem weiterhelfen soll. Ich muss online ja anzeigen, dass für die Buchung, weil sie länger als 10 Tage geht, Zwischenreinigungen möglich sind. Außerdem muss angezeigt werden, dass auf Wunsch kostenlos ein Abendessen möglich ist, weil es das freitags immer kostenlos gibt. Und weil die Buchung auch über zwei Montage und einen Mittwoch geht, sind bis zu drei zusätzliche Abendessen gegen Aufpreis möglich. Die zwei Kinder zahlen dabei weniger als die Erwachsenen. Wie hilft mir das bisher simple Datenbankmodell dabei weiter?

Das Problem ist ja, dass dies nur ein einziges Beispiel ist. Das System sollte so flexibel wie möglich sein, da es noch viele weitere Leistungen gibt und auch weitere hinzukommen werden. Preise, Maximalmengen, usw. sind von vielen Bedingungen abhängig.

Eine Lösung die mir eingefallen ist: Online im Backend eine Art Logik-Diagramm anbieten, wie es bei vielen Bugtrackern bei der Suchfunktion möglich ist. Dort für alle Angaben (Menge, Preis) ein Diagramm, welches mit Klammern und logischen Ausdrücken a "<Nächte> <größer als> <10>". Dabei muss man noch beachten, dass verschiedene Wohnungen sich Diagramme teilen könnten, es die gleiche Leistung aber auch unter verschiedenen Bedingungen geben könnte. Fazit: Flexibel, aber sehr umständlich, nicht wirklich einfach zu bedienen.

@Der schöne Günther: Mh, interessant. Ich werde mir das mal genauer anschauen und melde mich dann nochmal.

Liebe Grüße,
Valentin

[WM_CLOSE]

Du könntest auch ein Feld mit Bedingungen erstellen, die du eben vor dem Ausführen prüfst. z.B. mit Lua. Denn du kannst ja nicht, wenn die Geschäftsleitung auf die Idee kommt, katzen als Zusatzleistung einzuführen, den Quellcode der Anwendung überarbeiten.

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