komplizierte Join-Abfrage mit rechenoperatoren

[Rolf B]

Hallo hermesias,

Die Buchhaltungsanwendung mache ich gerade für einen sehr kleinen fast privaten Verlag.

Hoffentlich kennst Du alle rechtlichen Vorschriften, die dafür zu beachten sind. Wenn Du eine nicht beachtest, hast Du den Dreck am Hacken.

Ich werde wohl doch eine Spalte 'gesamtpreis' in der TBL_rechnungen

Kannst Du (aus anderen Gründen) machen, ist aber buchhalterisch unzureichend. Ein Warenkorb-Eintrag ist Grundlage für einen Buchungsbeleg, und deshalb musst Du den angesetzten Einzelpreis an den Positionen im Warenkorb speichern, würde ich mal behaupten. Ob das fachlich richtig ist, weiß ich nicht. Szenario: Kunde A legt Artikel X in den Warenkorb. Preis ist 12€. Kunde unterbricht, kommt später wieder, der Preis ist mittlerweile geändert worden auf 13€. Soll der Kunde beim Kauf 12€ oder 13€ vorfinden? Es ist ja noch ein Warenkorb und nicht die Rechnung, d.h. NOCH muss der Preis nicht fixiert sein.

Als Softwareentwickler mit fast 40 Jahren Berufserfahrung frage ich dich: Bist Du sicher, dass deine Fachkompetenz (auf Business-Seite, nicht auf Informatik-Seite) für eine Faktura ausreichend ist? Bist Du sicher, dass Du das billiger bauen und pflegen kannst als eine fertige Faktura zu kaufen bzw. als Cloudservice zu buchen? Oder ist das eine Legacy-Buchhaltung, die Du "geerbt" hast und am Laufen halten musst? In dem Fall prüfe die Idee einer Migration auf Standardsoftware. Cloud hat den Vorteil, dass die Datensicherung nicht mehr Dein Problem ist (oder nur dann, wenn der Cloudanbieter Scheiße baut).

Eine Spalte "Gesamtpreis" auf den Rechnungen wäre redundant - aber je nach Aufgabenstellung und Systembelastung wäre das eine brauchbare Performanceoptimierung. „Redundanz ist das Schmierfett einer Datenbank“, heißt es, und dementsprechend macht man sich damit die normalisierten Finger schmutzig.

Eine Alternative könnte sein, die Preise aus der Artikeltabelle auszulagern und je Artikel den gültigen Preis mit dem Zeitraum zu speichern, in dem er gilt. Das macht das SQL nochmal komplizierter, und es ist die Frage, ob irgendwer die historische Preisentwicklung nachhalten möchte. Ich glaube, den angesetzten Preis im Warenkorbposten zu speichern wäre besser. Es könnte ja auch Rabattaktionen geben, nicht jeder Artikel im Buchladen unterliegt der Preisbindung. Bzw. man kann sie mit Remittenden unterlaufen.

Was auch eine Frage wäre: Ist es sinnvoll, Rechnungsposten und Warenkorbeinträge gleichzusetzen? Rechnungsposten sind Buchhaltungsdaten, die per Definition unveränderlich sein müssen. Der Warenkorb sind operative Daten, die sich im Bestellprozess ständig ändern. Das sind zwei verschiedene Nutzungsprofile, insbesonderen haben sie unterschiedliche Anforderungen an Aufbewahrungsfristen und Datensicherung. Es wäre wohl eine gute Idee, nach abgeschlossenem Kauf die Zeilen aus dem Warenkorb in eine andere Tabelle zu verschieben, wo nur Rechnungsposten drin sind. Damit belasten sich das Bestellwesen und die Faktura nicht gegenseitig.

Aber bleiben wir erstmal dabei, dass das eine Tabelle ist.

Für deine gesuchte Query hat der Preis auf den Warenkorbeinträgen bzw. Rechnungsposten den Vorteil, dass Du einen Join weniger hast. Du hast nur noch Kunden --(1:n)-> Rechnungen --(1:n)-> Rechnungsposten. Das ist ein relativ einfacher Join.

Den Gesamtpreis für EINE Rechnungs-ID bekommst Du, wenn der Preis in die Warenkorbzeilen eingetragen wird, so:

SELECT SUM(w.menge*w.preis)
FROM  warenkorb w
WHERE w.r_id = ****

**** ist die Rechnungs-ID, für die der Preis bestimmt werden soll.

Diese Query setzt Du als Subselect in die Hauptquery ein:

SELECT kundendaten,
       rechnungsdaten,
       (SELECT SUM(w.menge*w.preis)
        FROM  warenkorb w
        WHERE w.r_id = r.r_id) gesamtpreis
FROM tbl_kunden k,
     JOIN tbl_rechnungen r ON k.k_id = r.k_id

und bekommst damit eine Spalte "gesamtpreis".

Man kann sowas auch per JOIN lösen, aber dann müsstest Du GROUP BY verwenden und dann muss jede nichtsummierte Spalte im GROUP BY aufgelistet werden.

Rolf