Fallweise Kombination von Einträgen

M

m6joe

Neuer Benutzer
Beiträge
3
Hallo zusammen!

Für ein Taxi-Unternehmen, welches an 3 Standorten mit Fix-Preisen arbeitet, versuche ich eine Standort-übergreifende Online-Preisliste zu erstellen.
Zur Erstellung der richtigen Abfragen liegen die Daten allesamt in selber Tabelle, letztlich sind mehrere relationale Tabellen vorgesehen:

Start, Ziel und der/die Knoten werden über 'ort' und 'knoten' festgelegt, daraus sollte dann der Preis aus der DB geholt werden, wobei man bis zu X Datensätze zusammenfügen muss:
  • Die Standorte sind als "Knoten" definiert über welchen sich grundsätzliche der Fahrpreis 'tarif' ergibt
  • Fahrten vom Knoten in eine Richtung werden über 'ort' mit gleicher Kategorie definiert => 'MAX(tarif)' der 2 gefundenen Einträge
  • Fahrten über denselben Knoten in entgegen gesetzter Richtung haben versch. Kategorien => 'SUM(tarif)' der 2 gefundenen Einträge
  • Fahrten wo Start & Ziel unterschiedliche Knoten haben benötigen als Verbindung eine Kombination mit einem Eintrag 'knonten_zu_knoten = 1' ebenso als 'SUM(tarif)'
  • Sortierung nach Belegung & Zeit ist ohnehin logisch und momentan nicht relevant.
Die Tabelle ist so aufgebaut
upload_2020-5-31_10-46-42.png

Der User wählt lediglich aus Start- & Zielort aus, den Rest soll das Script erledigen.

Die 1. Abfrage ist noch einfach:
SELECT tarif AS preis
FROM preise_proto
WHERE (ort = '$start' AND knoten = '$ziel') OR (ort = '$ziel' AND knoten = '$start')

Weitere Abfragen habe ich bisher mit if/else in PHP sortiert, logischer wird´s aber sicherlich, wenn ich die Abhängigkeiten bereits in der SELECT-Anweisung platzieren kann, nur hier stehe ich leider völlig im Dunkeln.

Somit meine Frage nach Tipps, ev. ähnlichen Erfahrungen Eurerseits?

Danke vorab, Joe
 
Werbung:
Schwer verständlich, was Du möchtest.
Vielleicht lieferst Du 2-3 Beispielfälle mit Daten und gewünschtem Ergebnis.
 
Fallbeispiel:

  1. Abfrage $start 'Finkenberg Dorf' => $ziel 'Mayrhofen'
    Start und/oder Ziel ist zugleich ein Knoten in diesem Fall 'Mayrhofen' => nimm den Eintrag, so wie er in der DB steht, ID 6 => € 17,00

  2. Abfrage $start 'Finkenberg Dorf' => $ziel 'Hintertux'
    Start und Ziel haben zwar den selben Knoten 'Mayrhofen' sind aber nicht Ziel => prüfe auf Kategorie, falls diese übereinstimmt JA 'Tuxertal' nimm den MAX(tarif) der beiden DB-Einträge ID 6/7 => € 52,00

  3. Abfrage $start 'Finkenberg Dorf' => $ziel 'Ramsau Bahnhof'
    Start und Ziel haben zwar den selben Knoten 'Mayrhofen' sind aber nicht Ziel, zudem unterschiedliche Kategorien - nimm den SUM(tarif) der beiden DB-Einträge ID 6/8 => € 30,00

  4. Abfrage $start 'Finkenberg Dorf' => $ziel 'Achenkirch Mitte'
    Start und Ziel haben keinen gemeinsamen Knoten ('Mayrhofen' bzw. 'Maurach')
    a) prüfe auf eine Verbindung knoten_zu_knoten => 'Mayrhofen' : 'Maurach' ......... ist vorhanden, ID 9 => 80,00
    b) nimm den Eintrag $start 'Finkenberg Dorf' wo Knoten 'Mayrhofen' ......... ist vorhanden, ID 6 => 17,00
    c) nimm den Eintrag $ziel 'Achenkirch Mitte' wo Knoten 'Maurach' ......... ist vorhanden, ID 10 => 20,00 SUM(tarif) daraus € 117,00

Das Skript zur Einsicht als ZIP-Anlage.
Wie gesagt: Moment läuft es bis Pkt. 2, bei Pkt. 3 gibt´s schon den einen oder anderen Denkfehler, weil nicht immer das korrekte Ergebnis kommt.
Zudem sortiere ich vor dem $sql-SELECT bereits über Variablen vor, was eigentlich ja nicht notwendig sein sollte.

THX
 

Anhänge

was bedeutet:
„Start und Ziel haben zwar den selben Knoten 'Mayrhofen' sind aber nicht Ziel“

Denn eine Spalte "Ziel" gibt es nicht, den Begriff Ziel gibt es in deiner Beschreibung nur als Parameter.
Dazu vielleicht passend die Frage: Wie sind die Angaben von Ort und Knoten gerichtet, ist eine Zeile (immer) in beiden Richtungen nutzbar? Das or in der Beispielabfrage deutet darauf hin.

Vorweg schon mal:
Deine Anforderungen ergeben auch ohne funktionierende Lösung die Notwendigkeit, eine bis mehrere Ergebniszeilen zu finden, abzufragen, zu verarbeiten. Dies je nach Datenlage und Start-/Zielparameter.
Angenommen, du schaffst die where Bedingung so zu formulieren, dass sie immer alle benötigten Zeilen liefert, müsstest Du sie auch gleichzeitig dem Abfragekriterium zuordnen, um zu wissen, wie das Erscheinen im Ergebnis zu interpretieren ist.

Naheliegender wäre eine mehrstufige Verarbeitung, die schrittweise mehr abfragt nach Bedarf. Damit würde man auch weniger Ressourcen benötigen. Evtl bietet sich hie eine Stored Procedure (bbzw. Function) an.



Dann noch zu den Spalten Belegung und Zeit:
Die Angaben in diesen Spalten sind so formuliert, dass sie nur mühevoll maschinell zu verarbeiten sind. Statt „1-3 Personen“ hilft wahrscheinlich eine 3 oder dann eine 5 für bis zu 5 Personen.
Bei der Zeit bietet sich wahrscheinlich eher ein Wertepaar oder eine Rangeangabe an.

Das angehängte Skript ist löblich und im Prinzip besser als ein Screenshot einer Tabelle, aber etwas umfangreich, um sich mal eben problemrelevante Stellen anzuschauen.
Das Create Statement und das Insertstatement gleich im ersten Post hätten gereicht, Du willst ja wahrscheinlich Deinen Helfern die Arbeit erleichtern.
 
klingt alles nach rekursiven Abfragen. Hab jetzt weder Zeit noch Lust, das mir im Detail anzusehen, zumal MySQL, ... falsche Datentypen wurden ja schon genannt.
 
Servus zusammen!

Danke für Eure Beiträge.
Eine Abfrage ist immer auch in die andere Richtung nutzbar - korrekt.

Was die WHERE-Bedingung angeht: Ich hatte schon befürchtet, dass DAS für meine Kenntnisse wohl zuviel sein wird, da werde ich wohl weit ausholen müssen.

LG
 
Werbung:
Ich frage mich, wie dieses Speichermodell funktioniert, wenn Objekte mal nicht wie im Beispiel nur die Täler entlang laufen, sondern irgendwo auch "im Kreis"...
Dein Modell geht vielleicht für eine Baumstruktur, aber eher nicht in einem Netz.
 
Zurück
Oben