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.

[Perlsau]

Zitat von Valle:

Und zwar 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.

Vor Jahren hatte ich einmal ein ähnliches Problem, als ich eine Anwendung erstellen mußte, die zur Verwaltung sehr verschiedener Artikel mit allerlei verschiedenen Merkmalen dienen sollte. Meine Lösung bestand darin, eine komplexe Merkmal-Struktur aufzubauen. Diese Merkmale konnten vom Kunden definiert und seinen Artikeln zugewiesen werden. In der DB geschah das in einer reinen Beziehungstabelle, die beim Anzeigen einfach nach dem jeweiligen Artikel-Index gefiltert und dann abgefragt wurde. Die eigentliche Artikel-Tabelle blieb beim Einbau der Merkmal-Geschichte völlig unberührt.

Beispiel: Du hast einen Artikel "Sommerkleid" in diversen Schnittmustern (kurzärmlig, Träger, halblange Ärmel), mit diversen Drucken (gepunktet, rot, blau, gruen) und verschiedenen Größen. Also gibt es drei Merkmale dieses Kleides: Schnitt, Druck und Größe. Ich lege also diese drei Merkmale in der DB an (falls sie noch nicht existieren) und lege danach drei neue Datensätze in der Artikel-Merkmal-Beziehungstabelle an, die zum einen den Index des Sommerkleides enthalten und zum anderen den Index des Merkmals. So kannst du jedem Artikel beliebig viele verschiedene Merkmale zuordnen. Beim Anzeigen muß ich dann nur die Beziehungstabelle nach dem Index des Sommerkleides filtern und habe so die drei Merkmale sofort parat.

[Furtbichler]

Ich habe hier etwas mit 'Plugins' gelesen. So (und mit noSQL) wurde eine polymorphe Produktdatenbank umgesetzt. Das Problem hier waren die sehr unterschiedlichen Eigenschaften, die wir in einem EVAM umgesetzt hatten.

Edit: Das EVAM ist eigentlich ein SQL-Antipattern, weil es in der Masse grottenlahm ist, aber wenn es nicht zu komplex ist, geht es noch.

Erschwerend (und damit für dich interessant) war die Tatsache, das es sich bei den Produkten um sehr komplexe elektrische Komponenten handelt, die allesamt Formeln und Algorithmen zur Berechnung physikalischer und geometrischer Eigenschaften benötigen. Weiterhin sind Eingabe und Designdialoge mit 40-100 Eingabefeldern je Produktkategorie nötig.

Zusätzlich war noch eine Skriptengine eingebaut, damit der Endanwender bestimmte Eigenschaften anhand anderer Eigenschaften ausrechnen kann.

Lösung: Plugins zur Berechnung, EVAM für die Daten und ASP.NET für die Dialoge. Alles in einer Produktklassentabelle konfiguriert. Wenn nun Produkt X bearbeitet werden soll, wird in in der Tabelle das Berechnungsplugin sowie der Dialog geladen und ausgeführt.

Bei Dir wäre das Ähnlich, wobei die Eigenschaften der Leistungen vielleicht nur 1-5 wären, wobei vielleicht nur 1-2 für den Anwender eingebbar sind. Damit würde dein individueller Dialog vielleicht nur eine Liste mit Textboxen sein.

Und die Businesslogik würde ich entweder skripten oder in einer DLL vorhalten....

Eine Skriptengine bietet dir die Möglichkeit, zur Laufzeit das Verhalten anzupassen.

[generic]

Zitat:

Ferienhaus 3 - Einkaufsservice - incl. - 0,00€

Inklusive schreibt man übrigens im deutschen mit K. Das betrifft auch die Abkürzung inkl.!

Incl. kommt von inclusive, ist also English und das kennen die meisten von Ihren Urlaub.
Dort wird es aber im Zusammenhang von "all inclusiv" verwendet, was auf Deutsch das "alles inklusive" heißt.
Was leider in dem Einzelhandel sehr gerne gemacht wird, mit englischen Begriffen rumschlagen wie z.B. Sale, Off und viele andere.


Aber kommen wir doch zum eigentlichen Problem:
Ich denke du würdest deinen Artikelstamm am liebsten vollständig in der Datenbank haben, ohne das Regeln im Code stehen.
Die Regeln bzw. die Leistungen könntest du natürlich in n:m Tabellen ablegen.
Wenn du weitere Regeln benötigst, dann kann man versuchen diese in der Zwischentabelle zu hinterlegen z.B. als Bitmap-Suche (bitte nicht an Bilder denken) oder ähnlichen Techniken.

[jobo]

[QUOTE=generic;1218571]

Zitat:

Dort wird es aber im Zusammenhang von "all inclusiv" verwendet, was auf Deutsch das "alles inklusive" heißt.

Wenn schon pingelig, dann aber bitte konsequent!

[Valle]

Hi,

@nahpets: Was du bisher beschreibst ist auch in der Tat trivial. Und existiert so auch schon. Die Webseite wird dir nicht viel bringen, es sei denn du wolltest direkt bei uns buchen. Dann müssten wir aber erstmal warten bis das auch fertig programmiert ist. ^^ Im Anhang findest du einen Ausschnitt aus unserem Wireframe, wie das in etwa umzusetzen ist.

Auf dem Screenshot sieht man: Die Webseite erkennt, dass ein Kind mitreist und sucht passende Optionen raus, die verfügbar sind. Hunde sind gegen Aufpreis pro Tag möglich, andere Tiere kostenlos. Weitere Leistungen sind auch zu sehen, je mit unterschiedlicher Preis-Berechnung. Dass der Transfer nur möglich ist, weil die Anreise an einem Freitag liegt, wäre eine mögliche Hürde. Weil die Buchung nur 7 Nächte hat, wird keine Zwischenreinigungsoption angezeigt. (Der Screenshot stammt vom firmenfremden Designer. Das ist nur ein Wireframe und kein Design oder tatsächliche Daten)

Wir haben selbstverständlich schon Ferienwohnungen, Buchungen, Leistungen, eine n:m-Relation zwischen den Ferienwohnungen und Leistungen und hunderte weitere Tabellen. Die Leistungen haben einen Namen, eine Beschreibung und einen Preis. Das reicht für unsere Mitarbeiter, weil die wissen, dass das Abendessen einmalig 15€ kostet, der Hund aber 15€ pro Tag. Und die wissen auch, dass die Leistung "Abendessen" nur auf einer bestimmten Menge an Ferienhäusern angeboten werden kann und nur an bestimmten Tagen. Diese Informationen bietet unsere bisherige Datenbankstruktur nicht. Und deine, soweit ich das sehe, auch nicht.

Wie ich diese Regeln in einer Datenbank jetzt formulieren soll; tja, das frage ich ja gerade. Ich kann dir beispielhaft zeigen wie es jetzt aussieht. Bisher gibt es lediglich einen Text im Kundenlogin und in E-Mails zum Kunden, der ihnen sagt, was jetzt inklusive ist. Das soll aber erweitert werden auf all das was noch zubuchbar und möglich ist; was also bisher unsere Büro-Mitarbeiter in Handarbeit machen. Das sieht (stark gekürzt) in etwa so aus:

Code:

Im Geamtpreis sind enthalten:
# if ferienhaus.id in (42, 21, 33, 34, 45, 75, 23, 22):
# if (buchung.bis - buchung.von)  > 5:
eine Zwischenreinigung
# elseif (buchung.bis - buchung.von)  > 10:
zwei Zwischenreinigungen
# endif
# elseif ferienhaus.id in (102, 54, 101):

Nur ein kurzer Ausschnitt. Leistungen sind also entweder inklusive oder optional. Falls optional, entweder kostenlos oder mit Aufpreis. Deren Verfügbarkeit richtet sich nach Kriterien wie Buchungsdauer, Anzahl Teilnehmer, Saison, Wochentage während der Buchung, Anzahl Erwachsene / Kinder / Babies uvm. Und das jeweils je nach Ferienhaus. Die maximale Menge an Zubuchungen einer Leistung richtet sich ebenfalls nach diesen Kriterien. Die Berechnung des Preises auch, wobei hier unterschieden werden muss zwischen pro Nacht, pro Person, pro Person und Nacht und evtl. noch mehr. Die bisherige Vielfalt an Kriterien und Leistungen ist, sagen wir, überschaubar. Aber sobald die technische Möglichkeit besteht mehr anzubieten, wird sich das ändern. Das System sollte jetzt so flexibel wie möglich sein. Konnte ich einigermasen klar machen, wo das Problem liegt?

@NamenLozer: Mh, deine Idee gefällt mir wirklich ganz gut. Ich denke das werde ich mal genauer durchplanen. Melde mich dann ggf. nochmal.

@Perlsau: Du beschreibst ja quasi nur eine einfache n:m Relation zwischen Ferienhäusern und Leistungen. Das hilft allerdings nicht viel, dann die Relation hilft mir nicht weiter, wenn Leistungen unter bestimmten Bedingungen angeboten werden können, die wiederrum von der Buchung abhängen. Auch ist die doch recht dynamische Berechnung des Preises damit nicht bewerkstelligt. Oder?

@Furtbichler: Das läuft dann ja im Wesentlichen auf ein ähnliches Prinzip wie bei NamenLozer heraus. Da wir nur Skriptsprachen verwenden, haben wir hier ja einen guten Vorteil. Einen Grund mehr, das System mit Plugins mal genauer unter die Lupe zu nehmen.

@generic: Unter Artikeln verstehst du vermutlich auch die Leistungen wie Zwischenreinigung usw. Ich könnte in der Relationstabelle weitere Felder hinzufügen, sowas wie "minimale Nächte der Buchung", "maxmimale ~", "muss Montag während der Buchung haben" usw. Allerdings währen das schon eine ganze Menge verschiedener Spalten. Man kann diese Kritierien auch in eine weitere Tabelle Auslagern, wobei beim Hinzufügen neuer Leistungen ja dennoch immer wieder Code geändert werden müsste. Wenn die Relationen abhängig von weiterem Bedingungen sind, dann kommen wir dem Plugin-System von NamenLozer ja wieder recht nahe.

Liebe Grüße,
Valentin