Moin!
Moin Sven
Danke erstmal für dein Statement. Ich bastel seit einiger Zeit mit SQL rum und finde es macht Spass damit zu arbeiten. Auf deine Frage hin warum Überkreuzt mit 2 tabellen.
Du hast diese Frage falsch verstanden.
Zwei Tabellen zu benutzen ist ok, aber die Aliasnamen überkreuz zu tauschen ist nicht ok.
Aliasnamen überhaupt zu benutzen ist nur sinnvoll, wenn man damit irgendwas erleichtert. Üblicherweise werden damit lange Tabellennamen abgekürzt, damit man an anderen Stellen nicht soviel tippen muß.
Konkret bei dir: Statt
FROM touren_kunden AS touren, touren AS touren_kunden
wäre
FROM touren_kunden AS tk, touren AS t
viel schlauer. Oder eben komplett ohne AS-Angaben.
Denn mit deinem jetzigen Statement bindest du die Tabelle "touren_kunden" unter dem Namen "touren" ein, und die Tabelle "touren" unter dem Namen "touren_kunden", was bedeutet: Wenn du vorne im SELECT oder hinten im WHERE die Spalte "touren.irgendwas" angibst, greifst du nicht auf die Tabelle "touren" zu, sondern auf die Tabelle "touren_kunden", weil du den Aliasnamen so gesetzt hast. Und das wird dann doch etwas verwirrend.
Das ist ungefähr so, als ob du von "Äpfeln" und "Birnen" sprichst, aber den Apfel als "Birne" und die Birne als "Apfel" bezeichnest. Solange du und jeder andere das weiß, ist das noch ganz witzig, aber sobald jemand das nicht weiß, wird er dir echten Birnensaft eingießen, wenn du "Birnensaft" verlangst, aber in Wirklichkeit Apfelsaft wolltest.
Der Updatebefehl sollte dazu beitragen das in der Spalte Erloese in der Tabelle touren der Betrag eingesetzt wird.
Das ist im Grundsatz schlechtes Tabellendesign. Man speichert keine Daten in separaten Spalten, die man errechnen kann. Weil sowas zu Inkonststenzen führen kann. Was ist, wenn sich die Ausgangszahlen verändern? Dann muß zwingend auch die Berechnung neu durchgeführt werden. Vergißt man das, oder kommt es zwischen Veränderung der Ausgangszahl und Neuberechnung der Ergebnisse zu lesenden Datenzugriffen, werden ungültige, zumindest aber falsche Daten, ausgeliefert.
Solche Ergebnisse sollte man wirklich nur dann speichern, wenn man dadurch erstens einen heftigen Performancevorteil erhält, zweitens diesen Vorteil auch wirklich benötigt, weil man nicht solange warten KANN, drittens dann ordentliche Caching-Mechanismen implementiert, die das vorberechnete Ergebnis vor Veränderungen der Ausgangszahlen löschen, damit eine Neuberechnung erzwungen wird, welche in keinem Fall falsche Ausgangswerte rausläßt, und viertens darf dieser Mechanismus natürlich nicht noch mehr Performance schlucken, als die ursprüngliche Berechnung. Das bedeutet insbesondere bei Ausgangswerten, die sich häufig ändern, dass so ein Caching eher nicht einsetzbar ist.
Kurzum ich wollte in einem Eingabefeld nur die Lieferscheinnummer eingeben und das SQL sollte mir den Erloes in die Spalte schreiben.
Warum willst du den Erlös speichern? Du kannst doch mit deinem Select und der darin enthaltenen Rechnung den Erlös jederzeit ausrechnen lassen. Das ist durchaus die übliche Vorgehensweise bei solchen Dingen.
Ich hab gerade mal mit den Update Befehlen rum gespielt, leider bekomme ich es nicht hin.
Ich schätze, das hängt wieder mal von der MySQL-Version ab. UPDATE ist in älteren Versionen nur in der Lage, auf eine einzige Tabelle zuzugreifen. Ein JOIN im UPDATE ist erst in irgendeiner 4er-Version möglich, das müßtest du mal genauer in der MySQL-Doku nachlesen. Insofern: Wenn deine MySQL-Version so ein Update nicht kann, dann kommst du ohnehin nicht drum herum, zuerst dein SELECT mit der Berechnung abzuschicken und dann für jedes Ergebnis ein UPDATE auf die Tabelle "touren" loszulassen - WHERE tour_ID = 'die tour_ID aus dem SELECT'.
- Sven Rautenberg