Komplexe, zubuchbare Leistungen abstrahieren

[jobo]

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 von p80286:

Zumeist wird dann das Beziehungsgeflecht dann klarer.

Das Geflecht ist für mich kein Geflecht, sondern eine Matrix in der alle Kombinationen gegeneinander aufgeführt sind (notfalls je Produkt oder -Gruppe)
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, ..)

[nahpets]

Zitat von jobo:

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.

Das sehe ich inzwischen auch so. Die ersten Jahre meiner Programmiererlaufbahn wollte ich auch immer alles im Programm implementieren, bis es irgendwann so komplext wurde, dass ich dort gescheitert bin. Dann musste ich mich (zwangläufig) mit einer Datenbanklösung auseinandersetzen und habe dann kapiert, wie genial einfach manches zu lösen ist, auch wenn die fachliche Komplexität extrem hoch ist.

Zitat von jobo:

Zitat von p80286:

Zumeist wird dann das Beziehungsgeflecht dann klarer.

Das Geflecht ist für mich kein Geflecht, sondern eine Matrix in der alle Kombinationen gegeneinander aufgeführt sind (notfalls je Produkt oder -Gruppe)
Ein Geflecht ist(oder wird) es dann, wenn man beginnt, diese Kreuzprodukt mit Regeln zu "vereinfachen".

Dies halte ich auch für richtig. Solange es noch ein Geflecht ist, ist es irgendwie nicht klar und man muss es besser formalisieren. Letztlich ist die Datenbank nichts weiters als die technische Vorhaltung des Inhaltes dieser Matrix.

Zitat von jobo:

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

Bei uns war es ein Umfeld, dass auch mal zum Wort des Jahres deklariert wurde und ein paar Jahre später zum Unwort des Jahres. Die Praxisgebühr kam darin auch vor Wer sich die dort anfallenden Regeln mal anschaut in Umfang und Komplexität, der hält das Problem hier (bei aller Komplexität) doch eher für "einfach". (Sorry, das ist jetzt nicht bös gemeint und soll auch niemanden herabwürdigen, Komplexität scheint mir ein durchaus subjektives Empfinden zu sein.) Und immer wieder der Rat: Aufmalen, aufschreiben, rein gedanklich kann kaum jemand so ein System auflösen und ein Design dafür erstellen. Ich weiß nicht, wieviele Quadrat(kilo)meter Tapeten wir für die Lösung von einzelnen Aufgaben gemalt haben, um irgendwie ein Bild vom (Teil)System zu bekommen.

Zitat von jobo:

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

Dies halte ich für ein extrem wichtiges Argument für eine Datenbanklösung. Hier kann man eine Oberfläche bauen und die Entscheider, Fachleute, Marketingmenschen... können selbst einpflegen, was sie haben möchten und sind ("sehr wichtig") auch für die Inhalte verantwortlich. Ist irgendeine Regel implementiert, so sind immer die Entwickler schuldig, egal wie unausgegoren, widersprüchlich, fehlerhaft... die fachliche Vorgabe war.

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

[Namenloser]

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.

[Valle]

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

[jobo]

Zitat von Valle:

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

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.

[nahpets]

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

[Robotiker]

Zitat von nahpets:

Hallo Valle,
So, und jetzt kommt der Teil, für den ihr mich alle für vollkommen bekloppt halten dürft

Eigentlich nicht, es erinnert mich nur etwas an den Nachbau einer Graphdatenbank mit relationalen Mitteln. Auch weil weiter oben eine Darstellung des Problems als Matrix und "Beziehungsgeflecht" erwähnt wurde.

[nahpets]

Hallo Robotiker,

Zitat von Robotiker:

Zitat von nahpets:

Hallo Valle,
So, und jetzt kommt der Teil, für den ihr mich alle für vollkommen bekloppt halten dürft

Eigentlich nicht, es erinnert mich nur etwas an den Nachbau einer Graphdatenbank mit relationalen Mitteln. Auch weil du weiter oben eine Darstellung des Problems als Matrix erwähnst, das wäre dann quasi die Adjazenzmatrixdarstellung der Graphdatenbank.

Doch, ich bin bekloppt (und fühl mich wohl dabei ). Das Wort Adjazenzmatrixdarstellung habe ich ja noch nie gehört. Die Suchmaschine meiner Wahl liefert mir dazu einige Ergebnisse, überwiegend von Seiten, deren Webadressen durchaus wissenschaftlich klingen. Was soll's. Angeklickt, gelesen, nix verstanden. (Ja, schon gut, sollte mir das mal etwas entspannter an einem oder zweidreivier schönen Abenden reinziehen.)
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:

Die Implementation des Algorithmus von Kruskal kann aus Programmen zusammengesetzt werden, die wir bereits untersucht haben. Erstens müssen wir die Kanten entsprechend der wachsenden Reihenfolge ihres Gewichts nacheinander betrachten.

Das heißt doch eigentlich, dass Valles Idee diesem entspricht und das Plugin mit dem niedrigsten Rückgabewert das höchste Gewicht hat.

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

[Namenloser]

[OT]

Zitat von nahpets:

Hallo Robotiker,

Zitat von Robotiker:

Zitat von nahpets:

Hallo Valle,
So, und jetzt kommt der Teil, für den ihr mich alle für vollkommen bekloppt halten dürft

Eigentlich nicht, es erinnert mich nur etwas an den Nachbau einer Graphdatenbank mit relationalen Mitteln. Auch weil du weiter oben eine Darstellung des Problems als Matrix erwähnst, das wäre dann quasi die Adjazenzmatrixdarstellung der Graphdatenbank.

Doch, ich bin bekloppt (und fühl mich wohl dabei ). Das Wort Adjazenzmatrixdarstellung habe ich ja noch nie gehört. Die Suchmaschine meiner Wahl liefert mir dazu einige Ergebnisse, überwiegend von Seiten, deren Webadressen durchaus wissenschaftlich klingen. Was soll's. Angeklickt, gelesen, nix verstanden. (Ja, schon gut, sollte mir das mal etwas entspannter an einem oder zweidreivier schönen Abenden reinziehen.)

Eine Adjazenzmatrix ist eigentlich was total einfaches. Sagen wir du hast einen Graphen mit den Knoten A,B,C und D. Zwischen zwei Knoten kann es höchstens eine Kante (Verbindung) geben.

Ein möglicher (ungerichteter) Graph wäre z.B. folgender:

Code:

A --- B
 \    |
  \   |
   \  |
    \ |
C --- D

Das kannst du aber auch so darstellen:

Code:

    A B C D
  +--------
A | 0 1 0 1
B | 1 0 0 1
C | 0 0 0 1
D | 1 1 1 0

Eine 1 in der Tabelle bedeutet einfach, es gibt eine Kante zwischen den Knoten, und eine 0 bedeutet, es gibt keine Kante.

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]

[Robotiker]

Zitat von nahpets:

Das Wort Adjazenzmatrixdarstellung habe ich ja noch nie gehört.

Oh, 'tschuldigung, ich wollte nicht mit Fachbegriffen um mich werfen. Ich dachte es wäre unter Programmieren allgemein bekannt, dass man einen Graphen nicht nur mit Kreisen und Pfeilen (Knoten und Kanten) darstellen kann, sondern auch als Tabelle mit einer Zeile und Spalte pro Knoten. Das ist die Adjazenzmatrix.

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 , 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