Bedingte Anweisung im MySQL-Query?

[Forumsgast]

Hallo Mitglieder dieses Forums,

vor ein paar Wochen hatte ich die Aufgabe bestimmte Informationen, die bei
uns per SQL erfragt werden, bei der Anfrage durch neuere aus einer weiteren
(aktuelleren) Tabelle zu ersetzen. (Es handelt sich dabei um eine neue
Bearbeitungsnummer, die anstelle der alten verwendet werden soll)

Wir haben dazu einen Dispatcher, der Anfragen an die Datenbank vorfiltert und
weiterreicht. Das Dispatcher-Skript darf dabei allerdings nicht verändert
werden, da es zu einem bereits (durch die Regulierungsbehörde) zertifizierten
Verarbeitungssystem gehört.

Die Anfrage selbst im Dispatcher-Skript (PHP) besteht aus zwei
verschiedenenen aufeinanderfolgenden Queries, die unterschiedliche Tabellen
(und Felder) ansprechen, da die Tabellen untereinander verknüpft sind. Die
Daten werden jeweils in einem Array gesammelt und abschliessend
zurückgegeben.

Hier mal stark vereinfacht dargestellt, wie das ungefähr aussieht:

function getData( $customer, $id, $filter='' )
{
    $data = array();
    $sql = "SELECT name, bid FROM tab1 WHERE id = '" . $id . "'" . $filter;
    [..]    // Daten werden überprüft und in $data umkopiert
    $bId = $result['bid'];

    $sql = "SELECT benutzer, kundennr, bestellnr FROM tab2 WHERE bid = '" . $bId . "'" . $filter;
    [..]    // Daten werden überprüft und in $data umkopiert
    [..]    // ... weitere Verarbeitungsschritte
    return $data;
} 

Jeder Query enthält bereits einen Platzhalter für einen Filter, der bislang nicht
oder nur wenig genutzt wurde (SORT, LIMIT), aber nun für diese Aufgabe
verwendet werden soll.

Die Bearbeitungs-Nummer-Abfrage (die erweitert werden soll) befindet sich im
ersten Query.

Normalerweise würde ich einen UNION-Befehl dafür verwenden, der das
Ergebnis des äusseren SELECTs einfach ersetzt:

$filter = " UNION SELECT name, bid FROM tab3 WHERE id = '" . $id . "'"; 

Soweit, so gut, aber da gibt es noch den zweiten Query in dem nichts
verändert werden soll, aber (zwangsläufig) denselben Filter verwendet. Fazit:
das Skript bricht (berechtigterweise) mit einem Fehler ab.

Ich hab's jetzt zwar aufgegeben, aber neugierig bin ich trotzdem: gibt es denn
überhaupt eine Möglichkeit diesen Filter beim zweiten Query unwirksam zu
machen bzw. gibt es einen Query, bei dem der Filter nur bei einer bestimmten
Bedingung wirksam wird? Eine "Bedingte Anweisung" im Query selbst also?

Ich wäre sehr dankbar für eure Hinweise und Ideen!
Ciao

[Forumsgast]

Versteh ich nicht. Was hindert Dich daran, die Filtervariable aus der Query herauszunehmen?

[Forumsgast]

"Versteh ich nicht. Was hindert Dich daran, die Filtervariable aus der Query herauszunehmen?"
Der Code im Dispatcher-Script darf nicht verändert werden. (Steht aber auch in meiner Beschreibung )

[Forumsgast]

Das Dispatcher-Skript darf dabei allerdings nicht verändert
werden, da es zu einem bereits (durch die Regulierungsbehörde) zertifizierten
Verarbeitungssystem gehört.

Mit Sicherheit gilt diese Zertifizierung dann aber auch im Zusammenhang mit der gesetzten Filtervariablen und dem zu diesem Zeitpunkt aktuellen Datenbanklayout.

Aber wie auch immer, ich befürchte, es gibt keine Bedingungslogik auf der Ebene von UNION bzw. ORDER BY, die die Verwendung derselben regeln kann. Bedingte Verknüpfungen etc. sind mir nicht bekannt.

[Forumsgast]

Mit Sicherheit gilt diese Zertifizierung dann aber auch im Zusammenhang mit der gesetzten Filtervariablen und dem zu diesem Zeitpunkt aktuellen Datenbanklayout.

Jein. Das DB-Layout könnte geändert werden, aber es kann nicht, weil das Verarbeitungssystem bereits feststeht. Und die Filter-Variable ist eine Variable und kann, muss aber nicht gesetzt werden. Allerdings stellt sie momentan den einzigen Lichtblick für uns dar, nicht mehr parallel und umständlich mit einem SQL-Client die neuen B-Nummern zu suchen, auszulesen und händisch zu ändern.

Aber wie auch immer, ich befürchte, es gibt keine Bedingungslogik auf der Ebene von UNION bzw. ORDER BY, die die Verwendung derselben regeln kann. Bedingte Verknüpfungen etc. sind mir nicht bekannt.

Ich hatte angefangen es mit den IF- und CASE-Statements zu probieren. Leider können dort nur statische Werte eingesetzt werden, keine Anweisungen oder Variablen.

Weiterhin hatte ich Set-Operanden im Visier z.B. CORR, allerdings gibt es den nur in der SQL-Syntax (soweit ich herausgefunden habe), nicht für MySQL. Damit hätte ich nämlich eine positionsweise Zuordnung von Feldern (ALL-Operand, per default gesetzt) durch CORR verhindern können, da das SELECT dann nur matchen würde, wenn gesetzte Spaltennamen übereinstimmen. (Das hätte mir z.B. gereicht, weil 'name' und 'bid' im zweiten Query nicht vorkommen). So aber scheitert ein Aufruf der Funktion mit Filter an der unterschiedlichen Anzahl der Spalten im zweiten Query und selbst, wenn das umgangen werden könnte überschreibt es dann ja auch Werte, die gar nicht verändert werden sollen.

[Forumsgast]

Ich hatte angefangen es mit den IF- und CASE-Statements zu probieren. Leider können dort nur statische Werte eingesetzt werden, keine Anweisungen oder Variablen.

Doch doch, das geht schon. Nur eben nicht in diesem Kontext.

[Forumsgast]

Doch doch, das geht schon. Nur eben nicht in diesem Kontext.

Na da bin ich jetzt aber neugierig! Vielleicht gibt's ja doch eine Möglichkeit...

[Forumsgast]

Also ich meine jetzt Ausdrücke und Spalten in IF/CASE Statements.

IF(`mycol` IS NULL , CONCAT(`othercol` , "(default)") , `mycol` * 1000) AS `level` 

sollte ohne Probleme funktionieren.

Nur ist das innerhalb des SELECT Zweiges oder der ORDER BY Struktur. Außerhalb wird das wohl nicht gehen.

[Forumsgast]

Okay. Scheint wohl nichts zu gehen.
Danke für die Mühe!

[Forumsgast]

Allerdings stellt sie momentan den einzigen Lichtblick für uns dar, nicht mehr parallel und umständlich mit einem SQL-Client die neuen B-Nummern zu suchen, auszulesen und händisch zu ändern.

Ihr "dürft" manuell an der Datenbank rumfummeln, aber kein neues Skript erstellen, das diesen Vorgang automatisch erledigt?

[Forumsgast]

Ihr "dürft" manuell an der Datenbank rumfummeln, aber kein neues Skript erstellen, das diesen Vorgang automatisch erledigt?

Das Rumfummeln beschränkt sich auf das Auslesen der Ids. Allerdings ist das ja gar nicht das Thema dieses Threads. Hast Du vielleicht eine Idee?

[Forumsgast]

Dürft Ihr der Datenbank einen View hinzufügen? Das würde allerdings auch bedeuten, dass der Dispatcher diesen View statt den eigentlichen Tabellen nutzen müsste, also nicht mehr SELECT ... FROM tab1 sondern SELECT ... FROM view1

Dürft Ihr eine Zusatzapplikation schreiben bzw. das Frontend erweitern, dass es die gelesenen Daten "nimmt" und die neuen Werte zusätzlich ausliest? Also im Prinzip das, was Ihr jetzt händisch macht automatisiert.