|
Komplexe, zubuchbare Leistungen abstrahieren
Hi DPler, :hi:
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) |
AW: Komplexe, zubuchbare Leistungen abstrahieren
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 |
AW: Komplexe, zubuchbare Leistungen abstrahieren
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. :wink: |
AW: Komplexe, zubuchbare Leistungen abstrahieren
Erstmal Danke für deine Antwort. :thumb:
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 |
AW: Komplexe, zubuchbare Leistungen abstrahieren
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.
|
AW: Komplexe, zubuchbare Leistungen abstrahieren
Zitat:
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. |
AW: Komplexe, zubuchbare Leistungen abstrahieren
@napeths :thumb:
Es kommt wohl darauf an aus welcher Ecke heraus man ein Problem versucht zu lösen. Gruß K-H |
AW: Komplexe, zubuchbare Leistungen abstrahieren
@p80286
Zitat:
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. |
AW: Komplexe, zubuchbare Leistungen abstrahieren
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. |
AW: Komplexe, zubuchbare Leistungen abstrahieren
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. |
AW: Komplexe, zubuchbare Leistungen abstrahieren
@mjustin
Zitat:
Zitat:
|
AW: Komplexe, zubuchbare Leistungen abstrahieren
Zitat:
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... |
AW: Komplexe, zubuchbare Leistungen abstrahieren
Hallo!
Vielen Dank für die vielen Antworten! :cyclops: 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. :P 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. :D 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 |
AW: Komplexe, zubuchbare Leistungen abstrahieren
Zitat:
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:
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:
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. |
AW: Komplexe, zubuchbare Leistungen abstrahieren
Zitat:
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. |
AW: Komplexe, zubuchbare Leistungen abstrahieren
Zitat:
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. |
AW: Komplexe, zubuchbare Leistungen abstrahieren
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. |
AW: Komplexe, zubuchbare Leistungen abstrahieren
Zitat:
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. |
AW: Komplexe, zubuchbare Leistungen abstrahieren
[QUOTE=generic;1218571]
Zitat:
|
AW: Komplexe, zubuchbare Leistungen abstrahieren
Liste der Anhänge anzeigen (Anzahl: 1)
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:
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?
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): @NamenLozer: Mh, deine Idee gefällt mir wirklich ganz gut. Ich denke das werde ich mal genauer durchplanen. Melde mich dann ggf. nochmal. :thumb: @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 |
AW: Komplexe, zubuchbare Leistungen abstrahieren
[OT]
Ich dachte immer Sale wäre ein riesiger Konzern - geleitet von einem Herrn Sale -, dem alle Geschäfte gehören und dieses mehrfach im Jahr durch sein Logo zum Ausdruck bringen will. Ein großer Mann, der Herr Sale :mrgreen: [/OT] |
AW: Komplexe, zubuchbare Leistungen abstrahieren
Zitat:
Du kannst dir ja mal bei der Firma Amirada (hab dort mal 4 Wochen gearbeitet) deren Katalogsystem anschauen. Deren Software ist in der Lage, jeden noch so komplexen Zusammenhang abzubilden. Intern arbeiten deren Module ebenfalls mit Merkmalen und Attributen (eine Unterkategorie der Merkmale). Dort habe ich dieses Prinzip auch kennengelernt.Ich blende mich jetzt aber hier mal aus, weil ich doch den Eindruck habe, daß es für dein Problem bereits bessere Lösungen gibt und ich gerade auch ein wenig zu tun habe. |
AW: Komplexe, zubuchbare Leistungen abstrahieren
Zitat:
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 ;-) |
AW: Komplexe, zubuchbare Leistungen abstrahieren
Hallo Valle,
mir wird klar, wo Dein "Problem" liegt. Die Frage ist eigentlich nicht, ob man die Regeln in einer Datenbank ablegen kann, sondern wie man dort Bedingungen ablegen kann. Vielleicht sollte ich mal dazusagen, dass ich regelmäßig per SQL SQL generiere und dann ausführe. Zumindest bei Oracle klappt das hervoragend. Wir haben mal ein System erstellen müssen, in dem es dutzende von Tabellen gab, in denen sehr variable Bedingungen abzulegen waren. Wir haben das in der Form gelöst, dass in den Tabellen quasi Teile der zu erstellenden Datenbankabfragen enthalten waren, aber so, dass nicht SQL-kundiges Personal in der Lage war, diese Bedingungen zu pflegen. Aus den Inhalten dieser Tabellen wurden dann zur Laufzeit per SQL SQL-Statements (bzw. die Wherebedingungen) generiert und dann ausgeführt. Das Ergebnis der so erstellten Abfragen wurde dann von Datenbankpackages oder Programmen weiterverarbeitet. Teils zur Befüllung neuer Tabellen oder zur Ausgabe von Listen, XML-Dateien... Wäre ein derartiges Vorgehen für euch eine Option? Ein Beispiel:
Code:
Das soll jetzt heißen: Beim Ferienhaus 1 gibt es den Zimmerservice kostenlos dazu, wenn das Ferienhaus über 5 Tage gebucht wurde, bei Ferienhaus 2, wenn mehr als 7 Tage gebucht wurde. Im Ferienhaus 3 gibt es keinen Zimmmerservice, ein Hund kostet insgesamt grundsätzlich 15 €. Im Ferienhaus 1 kostet das W-LAN pro Übernachtung 2,00 € und pro Person kann man pro Übernachtung für 4,50 € ein Frühstück erhalten.
Ferienhaus Ding Tage Preis ProPerson ProNacht
Ferienhaus 1 Zimmerservice >5 0,00€ - - Ferienhaus 1 W-LAN =1 2,00€ - ja Ferienhaus 1 Frühstück =1 4,50€ ja ja Ferienhaus 2 Zimmerservice >7 15,00€ - - Ferienhaus 3 Zimmerservice =0 0,00€ - - Ferienhaus 3 Hund =1 15,00€ - - Ferienhaus 4 Zimmerservice =7 0,00€ - - Ferienhaus 4 Hund >2 7,50€ - - Ferienhaus 5 Zimmerservice =7 2,00€ ja - Ferienhaus 5 Hund =1 0,50€ - ja Im Ferienhaus 4 gibt es alle 7 Tage einen kostenlosen Zimmerservice. Diese Leistung ist auch im Ferienhaus 5 verfügbar, dort kostet sie aber pro Person 2,00 €. Im Ferienhaus 4 kostet ein Hund bei einem Aufenthalt über 2 Tage pauschal 7,50 €, während im Ferienhaus 5 ein Hund pro Übernachtung 0,50 € kostet. Ergibt dies eine Vorstellung von dem, was ich meine?
Code:
Das kommt eigentlich sehr nah an meine Vorstellungen heran, nur würde ich versuchen dies per SQL abzubilden. Die FerienhausID würden wir in meinem Beispiel oben ja wiederfinden, Ferienhaus 1 steht dort ja nur der besseren Lesbarkeit wegen, in der DB wäre es der technische Schlüssel, ebenso bei den "Dingen". Wenn wir nun per SQL auf die Tabelle oben zugreifen, so finden wir den Wert > 5, die Zeitdifferenz zwischen buchung.von und buchung.bis können wir auch per SQL errechnen, kombiniert mit dem gefundenen > 5 ist also auch diese Bedingung gefunden und der Preis berechenbar.
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): Die Hürde, vor der Du stehst ist mir klar geworden. Ad hoc kann ich Dir jetzt auch nicht sagen, wie man das in eine Datenbank legt, dazu müsste man tatsächlich zuerst einmal einen möglichst vollständigen Überblick über die Regeln haben, um dann eine passende Struktur zu finden und zu entscheiden, wieviele Tabellen in welcher Struktur erforderlich werden. Klar ist aber auch, dass die Implementierung all dieser Regeln nur im Quelltext, egal ob ein Plugin oder n, erheblichen Aufwand bereiten wird und die Pflege extrem hoch werden kann. Solche Regeln darf es im Programmcode nicht geben:
Code:
Hier muss irgendeine Datenbasis herangezogen werden, so dass die Programmlogik sich auf die Berechnung für ein konkretes Ferienhaus beziehen kann.
if ferienhaus.id in (42, 21, 33, 34, 45, 75, 23, 22):
Ist es möglich für 2 oder 3 Ferienhäuser einmal eine (Excel)-Tabelle zu erstellen, in der alle Regeln ausformuliert dargestellt sind? Der Screenshot zeigt eigentlich genau das, was ich mir auch vorgestellt habe, beim Design scheinen die Vorstellungen nicht weit auseinander zu liegen. Perlsau beschreibt eigentlich mit seinen Worten sehr genau das, was ich meine. Momentan gehe ich noch davon aus, dass eine Datenbanklösung für euer System im Rahmen des Möglichen ist. Zitat:
Zitat:
@generic: Ich weiß seit ca. 50 Jahren, dass ich nicht richtig schreiben kann. Dafür stehen meine Schreibfehler unter der GPL und können von allen kostenlos jederzeit beliebig häufig genutzt werden. English schreibt man im Deutschen übrigens mit sch. Spar Dir bitte solche Belehrungen, sie sind für die Problemlösung nicht zielführend und zum Glück machst Du ja keine Schreibfehler ;-) |
AW: Komplexe, zubuchbare Leistungen abstrahieren
Um das Beispiel von Stephan aufzugreifen
Du hast folgende Reinigungsvorgänge nach 3 Tagen nach 7 Tagen alle 10 Tage Endreinigung Diese verknüpst du über Normleistung mit den Wohnungen, das ist dann die Leistung die nicht extra berechnet wird. Weiterhin hast Du die Tabelle Zusatzleistung in der mögliche Zusatzreinigungen für die Wohnungen aufgeführt werden: WohnID LeistungID Zuzahlung Buchungsbegin BuchungsdauerMin BuchungsdauerMax entfallendeNormLeistungID GGf müsstest Du eine weitere Tabelle mit entfallenden Leistungen einführen. Das kommt aber darauf an, wie komplex das entsprechende Beziehungsgepflecht ist. Auf jeden Fall kommst Du nicht mit 3 oder 4 Tabellen hin, und den Vorschlag einmal tabellarisch die verschieden Bedingungen auszuformulieren kann ich nur unterstützen. Zumeist wird dann das Beziehungsgeflecht dann klarer. Gruß K-H Gruß K-H |
AW: Komplexe, zubuchbare Leistungen abstrahieren
Ich plädiere für eine Datenbankrealisierung mit N:M Beziehungen und diversen Merkmalen. In dieser Form kann man jeden Pups definieren und natürlich wer mit wem.
Zitat:
Ein Geflecht ist(oder wird) es dann, wenn man beginnt, diese Kreuzprodukt mit Regeln zu "vereinfachen". Das ergibt evtl.,vielleicht eine schlankere Implementierung, am ehesten weniger Dateneingabeaufwand, aber der Teufel ist ein Eichhörnchen und die Marketingabteilung auch. Nahpets Schilderungen erinnern mich zumindest an solche Leute, die gefühlt immer mal wieder durchdrehen... Wie auch immer, wenn ich jede mögliche Kombi per "Klick" erlaube oder löschen kann, bin ich auf der sicheren Seite (und ich muss es nicht selbst machen, sondern die Marketingabteilung). In den Relationen kann man Einzelpreise, Inklusivpreise, (Mengen)rabatte usw. einbinden und regeln, ob das (Standard-)Produkt oder die aktuellste Rabatt-Option gewinnt. Dynamische Varianten wären durch Min/Max Person oder Min/Max Dauer Bereichsangaben zu realisieren. Wenn man Komfort bieten möchte (für Selektion und Definition der Merkmale) kann man diese noch mit Klassen versehen (ala Reinigung, Kinder, Haustiere, Lieferservice, Langzeit, ..) |
AW: Komplexe, zubuchbare Leistungen abstrahieren
Zitat:
Zitat:
Zitat:
Zitat:
@Valle, lass Dich jetzt bitte nicht von meinen Äußerungen verunsichern. Ich gehe davon aus, dass für eine Datenbanklösung bis zur Fertigstellung bei eurem System einige Mannmonate drauf gehen, selbst für das Datenbankdesign würde ich vermutlich einige Wochen brauchen. Aber wenn es dann einmal steht, habt ihr ein stabiles System, bei dem ihr nicht bei jedem Wunsch, jedem neuen Haus, jedem neuen Service, oder Katzen kosten jetzt auch was, Kaninchen aber nur die Hälfte... durch die Quelltexte müsst, um alle die Stellen zu lokalisieren, wo Änderungen erforderlich sind. Dies ist auf Dauer einfach zu fehleranfällig und macht Quelltexte irgendwann unbrauchbar. Das Redesign ist quasi schon vorprogrammiert. |
AW: Komplexe, zubuchbare Leistungen abstrahieren
Ich finde, die eigentliche „Komplexität“ liegt hier in der geforderten Flexibilität. Bei irgendwelchem Praxisgebühr-Kram, gibt es, nehme ich an, einheitliche, gesetzliche Regelungen, die sich auch höchstens alle paar Jahre mal ändern. Bei Valle ist es eher so, als ob jede Praxis ihre eigenen Gesetze hätte...
Aber ich finde es interessant, wie es hier anscheinend zwei Lager gibt. |
AW: Komplexe, zubuchbare Leistungen abstrahieren
Liste der Anhänge anzeigen (Anzahl: 1)
Hallo,
ich habe jetzt nochmal nachgehakt und noch eine ganze Menge weiterer Leistungen als Liste bekommen. Alles in allem ist die Menge an Bedingungen kaum weiter gestiegen und es handelt sich nach wie vor um die Variablen "maximal buchbare Menge" und "Preis" die individuell berechnet werden müssen. Die Liste ist hier vermutlich nicht wirklich hilfreich. Es kamen Dinge hinzu wie Heizung, Brennholz, Kinderspielzeug, Geburtstagskuchen, Fahrradverleih usw. @nahpets: Die Option SQL Statements in die Datenbank zu speichern klingt sehr spannend. Allerdings wird das technisch ein kleines Problem, da wir ausschließlich über einen ORM (SQLAlchemy) mit der Datenbank kommunzieren. Dieser mag sowas leider überhaupt nicht. Deine Beispieltabelle überzeugt auf den ersten Blick mit ihrer Einfachheit, ist aber bei genauerer Betrachtung wahrscheinlich nicht flexibel genug. Maximal zubuchbare Betten würden ein Problem geben und die Menge an Bedingungsspalten könnte immer weiter wachsen. Wenn ich keinen SQL Code dynamisch erzeugen kann, dann muss ich doch davon ausgehen, dass sich beim Hinzufügen weiterer Leistungen mit bestimmten Bedingungen weitere Logiken hinzufügen muss. Und da diese auf jeden Fall irgendwie programmiert werden müssen, egal ob in SQL oder Python, kommt man um eine von Programmierer herbeigeführte Änderung der Datenbank oder des Codes nicht herum. Also heißt das für mich, dass wir sowieso damit beschäftigt sein werden, bei neuen Leistungen auch neue Bedingungen und Preis-Algorithmen zu entwickeln. Wo das geschieht, kann uns als Entwickler im Prinzip dann ja egal sein. Da sich der SQL-Option aber aus technischen Gründen nicht wirklich anbietet, ist Code m.E. hier einfacher. Daher überlege ich im Moment an einer Mischung aus beiden Systemen. Weiterhin sind Ferienhäuser mit Leistungen über eine n:m-Relation verknüpft. Jeder Verknüpfung sind allerdings noch je ein oder mehrere weitere Einträge aus zwei weiteren Tabellen zugeordnet. Eine Verknüpfung der Zusatzleistung "Baby Hochstühle" mit dem Ferienhaus X enthält außerdem einen Fremdschlüssel in eine Tabelle mit allen möglichen "Preis-Berechnungs"-Plugins. Außerdem eine weitere n:m-Relation zu einer Tabelle mit allen "Maximal buchbare Menge"-Plugins. Im Anhang ist ein Diagramm wie ich mir das vorstelle. Die Preis-Tabelle hält sich nach aktuellen Kenntnisstand noch klein mit 4 Plugins für alle Permutationen von "pro Nacht" und "pro Person". Die Tabelle mit den Berechnungs-Plugins für maximal buchbare Menge enthält Plugins wie "nur im Winter" oder "maximal so viel wie Babys eingebucht". Da mehrere Plugins verknüpft werden können, gewinnt immer das Plugin mit der niedrigsten Mengenangabe. Maximalmenge wäre im Sommer dann eben 0, wenn "nur so viel Holz wie Nächte" zwar 7 sagt, aber "Holz nur im Winter" eben 0. Für jedes dieser Plugins existiert eine sehr einfache Klasse im Code. Eigentlich reicht schon fast eine Funktion. Natürlich muss dieser dann auch mal geändert werden. Allerdings müssen wir die Software ja an keine Kunden ausrollen, da wir die Software ausschließlich für uns verwenden. Wie ich finde, hat man damit die höchste Flexibilität bei geringstem Aufwand. Man könnte diese Plugins statt im Code auch in SQL realisieren. Allerdings sehe ich hier keinen Vorteil. Wir müssten erstmal unseren ORM davon überzeugen die zu verwenden. Und wo besteht für mich der Unterschied, ob ich SQL (z.B. Stored Procedures) oder Python entwickeln muss, wenn $chef was Neuen will? @NamenLozer: Ich finde die Diskussion auch recht interessant. Ich war bisher der Meinung, dass eine Datenbank hauptsächlich zuständig ist um Daten zu speichern, zu verwalten, aufzubereiten und herauszusuchen. Berechnungen von Verfügbarkeit und Preisen ist m.E. Logik, die eigentluch nicht in die Datenbank gehört. Die Frage ist allerdings, was einfacher ist. Ich kann mir schon vorstellen, dass größere Firmen sinnvollerweise da ganz andere Herangehensweisen haben. Ich freue mich auf eure Meinungen dazu und lasse mich auch gern verunsichern; denn dazu bin ich hier; sonst würde ich nicht fragen. :-) Liebe Grüße, Valentin |
AW: Komplexe, zubuchbare Leistungen abstrahieren
Zitat:
Die Diskussion dreht sich m.E. darum, ob ich ein Regelwerk implementiere oder "ganz billig" Fall für Fall bzw. gültige Kombinationen definiere(!). Daraus ergeben sich unterschiedliche Implikationen für Änderungen, Erweiterungen und auch Korrektheit. Eine DB Matrix kann jederzeit durch neue Datensätze in x/y Richtung erweitert werden, also neue Merkmale, ebenso kann durch Definition neuer N:M Relationen jederzeit die Merkmalskombination verändert werden. Das ist Insert/Update/Delete von Zahlen (ID) und Merkmalstexten. Regeln dagegen müssen durch Spezialisten durchdacht, geschaffen und deployed werden. |
AW: Komplexe, zubuchbare Leistungen abstrahieren
Hallo Valle,
so, jetzt kommt eine Antwort, die mich vermutlich ein paar Stunden kostet ;-) Aber es handelt sich hier um einen interessanten Denksport, ist also eine schöne Freizeitbeschäftigung. Was für ein Datenbanksystem habt ihr? (steht doch oben: MySQL) Anstelle der Plugins könntet ihr eventuell auch Datenbankfunktionen schreiben. Mal der Versuch eines Beispiels, die Funktion soll einfach nur den Preis für das WLAN berechnen, wie die Berechnung erfolgt, soll uns hier nicht kratzen, da das Ganze für das System transparent sein soll.
Code:
D. h.: Nach außen ist nicht sichtbar, was innerhalb der Datenbank eigentlich passiert.
select Name, ID, WLAN_Berechnung(ID,Tage,...,Personen) as WLAN_Preis
from Ferienhaus where id = :ParameterID Innerhalb der Funktion müsste es also möglich sein, beliebig SQL zu generieren und auszuführen (Oracle kann das, mit anderen Datenbanken habe ich in dieser Hinsicht keine Erfahrung), da davon ja nichts an die Außenwelt gelangt. Im Extremfall könnte es euch sogar gelingen, für jede Leistung eine Funktion zu schreiben, dann ein Select-Statement zu bauen, das nichts weiter ist als ein
Code:
(Sicherlich werden zwei Eingabeparamter nicht immer reichen, da Leistungen ja auch vom Buchungszeitraum... abhängig sein können. Eventuell wäre anzustreben, dass die Funktionen parameterkompatibel sind, auch wenn nicht überall alle Parameter erforderlich sind - Designfrage.)
select ID, Name,
Leistung1(ID, Menge) As Leistung1, Leistung2(ID, Menge) As Leistung2, Leistung3(ID, Menge) As Leistung3, ... LeistungN(ID, Menge) As LeistungN from Ferienhaus where ID = :ParameterID Eigentlich ist das nichts weiter als Plugins innerhalb der Datenbank. Flappsig formuliert: Für jede Leistung eine Funktion, die in das SQL des (einzigen?) Plugins rein und als Ergebnis kommt die vollständige Berechnung raus. Das Plugin müsste dann eventuell noch entscheiden, ob bei der Ausgabe an den Client das Ergebnis sichtbar oder unsichtbar sein soll. Dies ließe sich z. B. über den Rückgabewert der Funktionen steuern. Preise (davon gehe ich mal aus) sind immer >= 0 (wir wollen jetzt mal keine Boni oder Preisnachlässe berechnen - habt ihr sowas auch?). Dann könnte der "generalisierte" Rückgabewert -1 bedeuten: "In der Anzeige nicht sichtbar". Ist jetzt nur mal so dahingeschrieben, ohne irgendwie zuende gedacht zu sein. Mir ist momentan nicht klar, ob ihr bei jeder Leistung mit einem Rückgabewert auskommen werdet. Wenn nein, dann klappt das so nicht (auf Anhieb?). Funktionen kannst Du schreiben noch und nöcher und ändern wie Du willst, das sollte euer ORM eigentlich nicht mitbekommen (oder bin ich da zu naiv?). Eine andere Idee: Ihr greift nur über eine View auf die Datenbank zu. Davon ausghehend, dass das oben skizzierte funktionieren sollte, könnte der (oder die?) View so aussehen:
Code:
Euer ORM bekäme also immer nur genau das zu sehen.
select * from alles_was_es_gibt where ID = :parameterID
Die View enthält dann das oben skizzierte und damit wären auch Änderungen für die Ausgabe der Ergebnismenge in die Datenbank verschoben und das ORM dürfte sich eigentlich an keiner Dynamik mehr stören. (Ob das realisierbar ist, vermag ich nicht zu beurteilen.) So, und jetzt kommt der Teil, für den ihr mich alle für vollkommen bekloppt halten dürft ;-) Oben habe ich die mögliche Nutzung von Funktionen skizziert, die einen Rückgabewert haben und dazu dann die Frage gestellt, ob ein Rückgabewert ausreicht. Funktionen können auch Zeichenfolgen zurückgeben. Was spricht dagegen, dass sie bereits den fertigen Quelltext der auszugebenden HTML-Seite erstellen (bzw. das Fragment, das zur entsprechenden Leistung gehört? Bei Betrachtung des Screenshots für das mögliche Aussehen (von weiter oben) könnte es doch möglich sein den rechten Teil (Angebot 14740) zu generieren. Arbeitet ihr mit einer Sessionverwaltung? Die einzelnen Werte, die dort ausgegeben werden, müsste man dann sessiongebunden in der Datenbank ablegen, um sie für die weiteren Schritte, wie Buchung... vorrätig zu haben. Jede Leistungsfunktion benötigt hierzu als zusätzlichen Parameter eine SessionID (o. ä.), macht ihren Job und legt das technische Ergebnis entsprechend in einer Datenbanktabelle ab. Das "optische" Ergebnis gibt sie als Zeichenfolge zurück. Hat sie für den konkreten Einzelfall kein Ergebnis zu liefern, dann liefert sie einen Leerstring und in der HTML-Seite steht dort genau nichts. Euer ORM müsste also "nur noch" einen String als Ergebnis der View durchlassen ;-) Mir ist klar, dass eure Webseite mehr als nur pures HTML enthalten kann, aber eventuell ist es ja ein Denkanstoß für eine weitere Lösungsmöglichkeit. Hast Du schonmal mit Delphi dynamische Webseiten erstellt? Shaue Dir dort mal beim TPageProducer das Ereignis OnHTMLTag an, dass ist für meine Begriffe eine genial einfache Lösung. Grob sieht das so aus:
Code:
Es gibt dort die Tags <#ueberschrift> und <#content>. Wird nun eine HTML-Seite über den TPageProducer ausgeliefert, so tritt beim Auftreten eines Tags in der Form <#irgendwas> das Ereignis OnHTMLTag auf. In dem Ereignis kannst Du nun den Namen des Tags abfragen und abhängig vom Tag irgendwas machen. Hier beim Tag ueberschrift eben diese erstellen und zurückgeben. In der ausgelieferten Seite steht dann Dein Rückgabewert. Bei content könntest du jetzt eine Datenbankabfrage starten und die Ergebnismenge als Tabelle ausliefern, die gesamte Tabelle stände dann dort, wo bisher das Tag content steht. Geht sowas auch mit Python? Wenn ja, so könntet ihr hier euer Webseiten als Templates erstellen, an den gewünschten Positionen die Tags "einschummeln" und beim Auftreten eines Tags die entsprechende Datenbankfunktion aufrufen. Die liefert euch dann den passenden Inhalt, der ja auch beliebiges HTML enthalten kann und schreibt für die Session weitere Ergebnisse in die Datenbank.
<html>
... <body> <h1><#ueberschrift></h1> <hr /> <#content> </body> </html> Hier mal eine reales Template für meinen Webserver:
Code:
Abhängig von den Parametern, die die das Template nutzende ISAPI-DLL per Get oder Post bekommt, ist die Ausgabe der Seite unterschiedlich. Das Tag <#CSS> nutze ich z. B. um die Optik des (lokalen) Webauftrittes "mal eben" zu ändern. In der Konfiguration wird ein anderes Stylsheet eingetragen und schon ist die Optik für den gesamten Webauftriff verändert. Was Delphi da mitliefert ist hochflexibel, eventuell könnt ihr das ja auch mit Python nachbilden.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<!-- ppBibliothek.html --> <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> <meta http-equiv="expires" content="0"> <meta name="author" content="<#AUTHOR>"> <meta name="date" content="<#METADATE>"> <meta name="description" content="<#ERROR>"> <meta name="keywords" lang="de" content="<#MESSAGE>"> <meta name="robots" content="noindex"> <title><#TITLE></title> <link rel="stylesheet" type="text/css" href="<#CSS>"> <link rel="stylesheet" type="text/css" href="/stylesheets/neutral.css"> </head> <body background="<#BACKGROUND>"> <h1 align="center"><#TITLE></h1> <table align="center" width="100%"> <tr align="center" width="100%"> <td align="center"><a href="Bibliothek"><#IMGBUECHER>Bücher</a></td> <td align="center"><a href="Autor"><#IMGAUTOREN>Autoren</a></td> <td align="center"><a href="Kategorie"><#IMGKATEGORIEN>Kategorien</a></td> <td align="center"><a href="Verlag"><#IMGVERLAGE>Verlage</a></td> </tr> </table> <hr> <#CONTENT> </body> </html> Das mein ursprüngliches Beispiel zu "flach" war, ist mir durchaus klar, damit wollte ich nur versuchen, eine mögliche Herangehensweise zu verdeutlichen. Wenn ihr mit 'nem Dutzen Bedingungsspalten auskommen solltet, dann ist das sicherlich schon gut optimiert. Eventuell solltet ihr überlegen und prüfen, ob nicht pro Leistung eine eigene Bedingungstabelle sinnvoll ist. Bei einer Funktion pro Leistung (wie oben angedeutet) könnte das durchaus sinnvoll sein. Es gälte dann: Pro Leistung eine Funktion. Pro Funktion eine Bedingungstabelle. Damit dürfte eine Erweiterung (oder Reduzierung) um Leistungen recht einfach zu realisieren sein. Neue Leistung -> neu Funktion -> neu Tabelle. Das (optimalerweise) einzige SQL der Applikation um die Funktion erweitern. Die Anzeigeroutine entsprechend anpassen und fertig. Das Entfallen einer Leistung wäre dann auch so einfach. (Mir ist klar, dass auch dieses "Einfach" noch sehr viel Arbeit sein kann, aber mein Ziel ist es immer möglichst wenig viel Arbeit zu haben.) Deinem letzten Beitrag meine ich aber entnehmen zu können, dass für Euch das Prinzip und der Umfang der Berechnungsanforderungen weitgehend klar ist und eigentlich nur noch offen ist, für wieviele unterschiedliche Leistungen die Berechnung erfolgen muss, also die Anzahl der Leistungen unbekannt ist, das Regelwerk aber (vermutlich) nicht weitere Komplexität erhalten wird. Das ist schonmal eine wesentliche Erkenntnis, um sich konkrete Gedanken zur Umsetzung zu machen. Warum ich (heute) immer alles in der Datenbank haben will: Die praktische Erfahrung (weitgehend mit Oracle) ist halt die: Die Datenbank kann vieles schneller als ein Programm, da man die Datenmenge innerhalb der Datenbank bereits (per SQL) auf möglichst geringe Ergebnismengen einschränken kann. Es ist halt ein Unterschied, ob ich der Datenbank sagen kann: Liefere mir die Ergebnismenge für die Berechnung XYZ, anstatt sagen zu müssen: Liefere mir alle Daten und dann mache ich die Berechnung in meinem Programm. Dabei will ich nichtmal ausschließen, dass das Programm die eigentliche Berechnung (marginal?) schneller machen kann. Der Flaschenhals ist hier eher das durch die Gegendschieben von großen Datenmengen. Hier im konkreten Fall mag dies zu vernachlässigbaren Unterschieden führen. Bei 100ten-Millionen von Datensätzen, zusammengesucht aus mehreren Tabellen, kann da aber schonmal das eine oder andere Stündchen (Tag(e)) draus werden. Vor allem dann, wenn man von der Datenmenge nur eine Teilmenge benötigt, also im Programm weitere Ausschlußkriterien berücksichtigen muss oder eigentlich nur Summierungen nach verschiedenen Kriterien vornehmen muss. Es ist aber immer eine Gratwanderung, was ist jetzt im konkreten Einzelfall sinnvoller. Ein definitiv Richtig oder Falsch gibt es hier nicht. Bei aller Logik in der Programmierung: Man braucht da auch ein gesundes Bauchgefühl. Es ist nicht alles logisch erklärbar, was am Ende richtig funktioniert. Natürlich werden bei dem System die Programmierer nicht überflüssig, Du sollst Deinen Job jetzt nicht durch das Erstellen dieses Systems wegrationalisieren und Deine Kolleginnen und Kollegen sollen auch nicht brotlos werden, aber wenn sich Dateninhalte zu vorhandenen Leistungen ändern, sollte ein Eingriff in den Programmcode nicht (mehr?) erforderlich sein. Wenn ich mir mein Geschreibsel so anschaue, so scheine ich immer weiter in die Datenbank zu wandern ;-) Vor Jahren habe ich aber auch mal Software geschrieben, bei der bestimmte Prüfungen innerhalb der Datenbank auch auf die Konsistenz der Daten innerhalb von Tabellen, aber auch tabellenübergreifend erforderlich waren. Zum Entwicklungszeitpunkt war uns aber nicht bekannt, wann denn welche Prüfung erforderlich war. Dazu haben wir dann eine Tabelle erstellt, in der drinnestand, welche Prüfung wann erforderlich war. Dies konnte von der Fachabteilung beliebig geändert werden, auch die Reihenfolge der Aufrufe der einzelnen Prüfungen. Das kommt eigentlich Deinen bisherigen Vorstellungen mit den Plugins recht nahe. Ob in der Datenbank nun konfiguriert ist, wann welches Plugin außerhalb der Datenbank aufgerufen wird oder innerhalb, das ist sicherlich auch Geschmacksache und eine Frage, ob man etwas, dass man außerhalb der Datenbank abwickeln kann, auch gleichwertig innerhalb der Datenbank abwickeln kann. Die zu treffende Entscheidung ist sicherlich auch wesentlich davon abhängig, was das Datenbanksystem, neben der eigentlichen Datenhaltung, zu leisten vermag. Betrachten wir hier das ganze Geschreibsel also mal als "Brainstorming" und da ist dann auch mal der eine oder andere Unsinn zulässig, eventuell hilft er auf neue Ideen zu kommen, ansonsten wird er verworfen und vergammelt irgendwann im digitalen Nirvana ;-) Zitat:
@Namenlozer Zitat:
Dein letzter Satz trifft das Ganze schon sehr gut, der Vergleich zwischen Praxis und Ferienhaus ist eventuell etwas zu "drastisch", aber für die ärztlichen Fachgruppen ist er durchaus vergleichbar. Das käme einer Typisierung der Ferienhäuser gleich. Für Ferienhaustyp A gilt: ... Für Ferienhaustyp B gilt: ... Für ärztliche Fachgruppe A gilt: ... Für ärztliche Fachgruppe B gilt: ... Für mich sind die Unterschiede da garnicht so groß, wenn ich ein kleines System so flexibel abbilden kann, dann kann ich mit dieser Logik auch ein großes System abbilden. Dein Hinweis ist absolut korrekt: Man muss die Flexibilität erkennen. Auch sollte man versuchen in der Komplexität Systematiken zu erkennen. Dadurch lassen sich dann eventuell Teilkomplexe bilden, die man (mit viel Glück) nach einem Schema weiterbehandeln kann. Das ist oft "einfach" nur Gehirnjogging. @Valle: Ließe sich euer System durch die Einführung von Ferienhaustypen vereinfachen? Gibt es z. B. hunderte oder dutzende von Ferienhäusern, für die die gleichen Regeln gelten. Dadurch könnte dann die Menge der Einträge in den Bedingungstabellen reduziert werden und gibt es eine Änderung bei einem Typ muss nur dieser geändert werden und nicht aller Ferienhäuser, die diesem Typ entsprechen (reduziert den Pflegeaufwand und die Datenmenge in den Bedingungstabellen, auch die Fehleranfälligkeit bei der Pflege dürfte sinken). Naja: Und wenn es dann ein paar Typen gibt, die nur über ein Ferienhaus verfügen, so ist das auch kein Beinbruch. Perlsau hat weiter oben ja beschrieben, dass dies für Artikel eine durchaus gangbare Vorgehensweise ist. Zitat:
So, genug für's Erste ;-) Eventuell vorhandene Schreibfehler stelle ich der Allgemeinheit zur Verfügung ;-) |
AW: Komplexe, zubuchbare Leistungen abstrahieren
Zitat:
|
AW: Komplexe, zubuchbare Leistungen abstrahieren
Hallo Robotiker,
Zitat:
Wenn ich mir die Bilder auf dieser Seite anschaue http://www.imn.htwk-leipzig.de/~medo...ge1/k31t4.html, ja, so stelle ich mir das, was hier abgebildet werden soll, vor. Nicht im Detail so, aber vom Grundsatz schon. Aber damit werden wir hier dann wohl ein bisserl OT.Das, was auf der Seite oben steht, erläutert eigentlich auch den Vorschlag von Valle, dass das Plugin "gewinnt", dass den niedrigsten Wert zurückgibt, dies entspräche dann der kürzesten Kante. Passt das so inetwa? Auf der Seite steht auch Zitat:
Wäre von selbst nie auf die Idee gekommen, dass man die Lösung der hier anstehenden Aufgabe auch wissenschaftlich betrachten könnte, weil ich befürchte, sie dann nicht mehr zu verstehen und lösen zu können ;-) |
AW: Komplexe, zubuchbare Leistungen abstrahieren
[OT]
Zitat:
Ein möglicher (ungerichteter) Graph wäre z.B. folgender:
Code:
Das kannst du aber auch so darstellen:
A --- B
\ | \ | \ | \ | C --- D
Code:
Eine 1 in der Tabelle bedeutet einfach, es gibt eine Kante zwischen den Knoten, und eine 0 bedeutet, es gibt keine Kante.
A B C D
+-------- A | 0 1 0 1 B | 1 0 0 1 C | 0 0 0 1 D | 1 1 1 0 Wenn die Kanten gewichtet sind, dann sind zusätzlich zu 0en und 1en halt noch weiterere Werte möglich. Die Zahl gibt dann an, „wie stark“ die Knoten verbunden sind. [/OT] |
AW: Komplexe, zubuchbare Leistungen abstrahieren
Zitat:
Was ich eigentlich sagen wollte, ist dass das was Du da mit Oracle machst, mich stark daran erinnert, was die NoSQL-Leute z.B. mit Neo4j machen http://www.neo4j.org/sprich es gibt Datenbanken die solche "Beziehungsgeflechte" sehr einfach darstellen können. Appropos Geflecht, ich bin mir nicht mal sicher, ob das Beziehungsgeflecht der Optionen, um die es in diesem Thread eigentlich geht, einer Graphdatenbank bedarf. Wenn der Graph eher konstant ist, gäbe es da, zwar nicht in Delphi aber in RAD-Studio :oops:, eine mächtige Bibliothek, die in Knoten und Kanten eines Graphen auch Programmcode unterbringen könnte ... http://www.boost.org/doc/libs/1_53_0...doc/index.html |
AW: Komplexe, zubuchbare Leistungen abstrahieren
[OT]
Hallo NamenLozer, das ist mir jetzt noch zu hoch. Fahren wir mal Eisenbahn. In Deinem Beispiel seien A, B, C, D irgendwelche Orte mit Bahnhof, ich kann damit also feststellen, von welchem Ort ich zu welchem Ort fahren kann. Also von A komme ich nach B und nach D. Wenn wir jetzt hergehen und für A, B, C, D weitere Matrizen aufstellen, z. B. für A, E, F, G:
Code:
Desgleichen noch für B, C, D und weitere Orte, so kann ich mich hier quasi von Matrix zu Matrix hangeln, um letztlich einen Weg von z. B. D nach G zu finden, der hier also über A führt, wo ich aber umsteigen muss.
A E F G
+-------- A | 0 0 0 1 E | 0 0 1 0 F | 0 1 0 1 G | 1 0 1 0 Wenn ich jetzt die beiden Matrizen zusammenfasse (heißt das so?) käme dann das dabei raus?
Code:
Also schaue ich in A stehend wohin ich kann. Das sind B und D. Nun schaue ich für B nach, wohin ich kann, das sind A und D. das passt mir nicht. Jetzt schaue ich für D nach, wohin ich kann, das sind A, B, C und G. Und schon habe ich meine Route ;-)
A B C D E F G
+-------------- A | 0 1 0 1 0 0 0 B | 1 0 0 1 0 0 0 C | 0 0 0 1 0 0 0 D | 1 1 1 0 0 0 1 E | 0 0 0 0 0 0 0 F | 0 0 0 0 0 0 0 G | 0 0 0 1 0 0 0 (Da meldet sich im Hintergrund eine Stimme, die mich dran erinnert: Da war mal was mit Matrizenmultiplikation! - gehört das hierhin?) Ok, ist eigentlich nix anderes, als das, was Valle hier benötigt, um die Bedingungen für Leistungen und die entsprechenden Abhängigkeiten von Buchungszeitraum ... feststellen zu können. Eigentlich ganz einfach kompliziert oder lieber kompliziert einfach? ;-) Oder die simple Programmiererregel: Zerlege ein Problem solange in kleinere Schritte, bist Du es umsetzen kannst. Und das scheint mir hier beim Ferienhausbuchungsprojekt das Wesentliche zu sein, danach ist das dann "nur noch" Fleißarbeit. @Robotiker Zitat:
Das was mit neo4j gemacht werden kann ist also u. a. die optische Darstellung der Datenbankinhalte a la UML. (?) Das Bild möchte ich für das hier diskutierte Problem gerne mal sehen, um sehen zu können, ob meine Vorstellungen mit der Realität in Einklang zu bringen sind ;-)[/OT] |
AW: Komplexe, zubuchbare Leistungen abstrahieren
Zitat:
Man könnte mit den Kanten Beziehungen, wie "ist Zubuchoption von", "enthält", "schliesst aus", "muss kleiner sein als", usw. darstellen. Man muss das nicht in Tabellen modellieren. Im Prinzip läuft das auf eine ähnliche Lösung hinaus, wie in dem Beitrag von Furtbichler oben, aber mit einer anderen Art von NoSQL-Datenbank und eventuell unter dem Verzicht auf explizit geschriebenen Plugins, die könnte man z.B. mit Graph Rewriting aus der Datenbank ableiten, z.B. so http://en.wikipedia.org/wiki/GrGen |
AW: Komplexe, zubuchbare Leistungen abstrahieren
@Robotiker
Zitat:
Zitat:
Bisheriges Fazit aus diesem Thread: Es gibt viele Wege nach Rom und Valle bekommt jetzt das Problem zu entscheiden, welcher Weg der für ihn der Beste ist. |
AW: Komplexe, zubuchbare Leistungen abstrahieren
Zitat:
Manchmal ist es aber so, wie oben bei der Graph- und Matrixdarstellung, dass man es mit zwei Seiten einer Medaille zu tun hat. Dann kann es hilfreich sein, auch mal auf die andere Seite zu schauen, sei es auch nur um das Problem besser zu verstehen. Wenn man z.B. sehr viele n:m Beziehungen einführt (wie "enthält", "schliesst aus" usw.) und die auch noch rekursiv durchsuchen muss, dann sollte man schon mal an eine Speicherung als Graph denken, da kriegt man das dann quasi mit Automatikgetriebe. |
AW: Komplexe, zubuchbare Leistungen abstrahieren
[OT]
Zitat:
Allerdings macht deine zusammengefasste Matrix irgendwie keinen Sinn. Da steht jetzt z.B. dass du von D nach G gehen kannst, dabei gibt es gar keine Verbindung zwischen D und G. Auf der anderen Seite müsstest du von A nach G kommen, aber da steht bei dir eine 0. Und alle anderen Verbindungen von deiner AEFG-Matrix fehlen irgendwie auch... Ich kenn es außerdem eigentlich auch nur so, dass es eine Adjazenzmatrix gibt, in der alle Knoten-Kombinationen drin sind, und nicht mehrere Ajazenzmatrizen für Teilgraphen, die erst noch kombiniert werden müssen. Aber ich verweise jetzt einfach mal auf diese Vorlesungsfolien (oder hier das etwas ausführlichere Skript, ab Seite 101 geht’s los), damit wir nicht noch weiter ins Off-Topic abdriften.[/OT] |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 20:39 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz