Komplexe, zubuchbare Leistungen abstrahieren

[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

[nahpets]

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

    A E F G
  +--------
A | 0 0 0 1
E | 0 0 1 0
F | 0 1 0 1
G | 1 0 1 0

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.

Wenn ich jetzt die beiden Matrizen zusammenfasse (heißt das so?) käme dann das dabei raus?

Code:

    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

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

(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 von Robotiker:

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.

Da brauchst Du Dich nicht zu entschuldigen, es gibt im großen Netz genug Möglichkeiten zu suchen und (fast) alles an Antworten zu finden. Hat mich jetzt ja auch nur 'ne Minute gekostet. Mit Fachbegriffen stand ich schon immer auf Kriegsfuß, eigentlich habe ich von der Theorie keine Ahnung, baue aber trotzdem (verblüffenderweise) Lösungen zu Problemen, bei denen andere sagen, das geht doch garnicht. Allerdings nur im kaufmännischen Bereich, technische Erfahrungen fehlen mir vollkommen.

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]

[Robotiker]

Zitat von nahpets:

Das was mit neo4j gemacht werden kann ist also u. a. die optische Darstellung der Datenbankinhalte a la UML.

Nein, das ist kein Grafiktool. Das ist eine Datenbank, aber ohne Tabellen, sondern mit Knoten und Kanten, an denen Eigenschaften hängen.

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

[nahpets]

@Robotiker

Zitat von Robotiker:

Zitat von nahpets:

Das was mit neo4j gemacht werden kann ist also u. a. die optische Darstellung der Datenbankinhalte a la UML.

Nein, das ist kein Grafiktool. Das ist eine Datenbank, aber ohne Tabellen, sondern mit Knoten und Kanten, an denen Eigenschaften hängen.

So hatte ich das auch nicht aufgefasst, sondern nur eher beim Ergebnis der Darstellung. Gut, da habe ich (noch) keine Ahnung. Muss ich mir mal intensiv anschauen.

Zitat von Robotiker:

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

Also eigentlich ein vollkommen anderer Weg, um das hier diskutierte Problem lösen zu können.

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.

[Robotiker]

Zitat von nahpets:

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.

Das wird bei einem solchen Thema zwangsläufig der Fall sein. Und wir haben sicher noch nicht alle Möglichkeiten ausgelotet.

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.

[Namenloser]

[OT]

Zitat von nahpets:

Wenn wir jetzt hergehen und für A, B, C, D weitere Matrizen aufstellen, z. B. für A, E, F, G:

Code:

    A E F G
  +--------
A | 0 0 0 1
E | 0 0 1 0
F | 0 1 0 1
G | 1 0 1 0

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.

Wenn ich jetzt die beiden Matrizen zusammenfasse (heißt das so?) käme dann das dabei raus?

Code:

    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

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

(Da meldet sich im Hintergrund eine Stimme, die mich dran erinnert: Da war mal was mit Matrizenmultiplikation! - gehört das hierhin?)[/OT]

Ja, wenn du die Adjazenzmatrix mit sich selbst multiplizierst, dann bekommst du für jeden Knoten die Knoten, die du mit genau 2 Schritten erreichst. Wenn du dann noch mal die Matrix dranmultiplizierst kriegst du die Knoten, die du mit 3 Schritten erreichst usw...

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]