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:
select Name, ID, WLAN_Berechnung(ID,Tage,...,Personen) as WLAN_Preis
from Ferienhaus where id = :ParameterID
D. h.: Nach außen ist nicht sichtbar, was innerhalb der Datenbank eigentlich passiert.
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:
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
(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.)
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:
select * from alles_was_es_gibt where ID = :parameterID
Euer ORM bekäme also immer nur genau das zu sehen.
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:
<
html>
...
<body>
<h1><#ueberschrift></h1>
<hr />
<#content>
</body>
</
html>
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.
Hier mal eine reales Template für meinen Webserver:
Code:
<!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>
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.
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 von
Valle:
... und lasse mich auch gern verunsichern; denn dazu bin ich hier; sonst würde ich nicht fragen.
Eine sympathische Einstellung, frei nach dem Motto:
"Der Kopf ist rund, damit die Gedanken auch mal die Richtung ändern können."
@Namenlozer
Zitat von
Namenlozer:
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...
Die Praxisgebühr war nur deshalb im Text, damit ihr wisst, aus welchem Umfeld der "Spaß" kam. Sie dürfte eine der wenigen Konstanten im System (gewesen) sein. Es gibt in dem Umfeld dutzende Verträge mit Leistungerbringern und Leistungträgern, die Budgetierung... Da steht am Anfang der Abrechnung noch nicht fest, was die einzelne Leistung letztlich dem einzelnen Leistungserbringer einbringen wird. Das System ist absolut nicht statisch, gesetzliche und vertragliche Änderungen sind der Normalfall und nicht die Ausnahme, zumindest nach meinem subjektiven Empfinden. Aber das Thema sollten wir hier nicht vertiefen.
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 von
jobo:
Also die Frage, wo die (Business-)Logik liegt, ist ebenfalls spannend, aber hier nicht der Kern.
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.
Diesen Gedankengang sollte man keinesfalls außer acht lassen.
So, genug für's Erste
Eventuell vorhandene Schreibfehler stelle ich der Allgemeinheit zur Verfügung