Multiplikation 2er Spalten

Maximus_d69979 · 10. November 2019 um 16:52

Hallo Wissende,

ich habe hier eine Tabelle nach folgendem Schema:

Artikel | Preis | Anzahl | Summe
bla…| 3…| 2…| 6
blubb…| 5…| 7…| 35

Nun moechte ich, dass beim INSERT die Summe, besser das Produkt, automatisch ergaenzt wird.
Sprich ich gebe nur ein:

INSERT INTO table (Artikel, Preis, Anzahl) VALUES (dings, 3, 3);

Die Summe soll jetzt automatisch uebernommen und ergaenzt werden.
Ich will NICHT, dass erst bei der SELECT Abfrage die Summe berechnet wird.

Wie kann ich das realisieren? Funktioniert das nur mit VIEWS oder kann ich direkt beim Erstellen der Spalte einen Parameter mit angeben?

MfG Maximus

Maximus_d69979 · 10. November 2019 um 16:52

Also die Sache mit Views zu loesen hab ich hinbekommen.

CREATE VIEW new_table (artikel, preis, anzahl, summe) AS SELECTED artikel, preis, anzahl, preis*anzahl FROM old_table;

Gibts trotzdem noch eine Loesung ohne Views?

MfG Maximus

muzel_c91186 · 10. November 2019 um 16:52

Hallo Maximus,

obwohl mir die Variante mit View viel besser gefällt, gäbe es z.B. noch Trigger. Syntax abhängig von deiner nicht erwähnten Datenbank.
http://de.wikibooks.org/wiki/Oracle:_Trigger

Gruß, muzel

Maximus_d69979 · 10. November 2019 um 16:53

Die Loesung gefaellt mir

Es ist uebrigens eine SQL DB.

MfG Maximus

Ulrich_Vaid · 10. November 2019 um 16:54

Hallo,

Ich würde die Trigger vermeiden…

Warum berechnest du den Wert nicht gleich beim Einfügen, du machst ja das Insert auch selbst ?

—> INSERT INTO table (Artikel, Preis, Anzahl, SUMME) VALUES (dings, 3, 3,(preis*anzahl));

Gruss

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

Maximus_d69979 · 10. November 2019 um 16:55

Stimmt, das ist wahrscheinlich die beste Loesung.

MfG Maximus

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

muzel_c91186 · 10. November 2019 um 16:55

Es ist uebrigens eine SQL DB.

Wer hätte das gedacht.

—> INSERT INTO table (Artikel, Preis, Anzahl, SUMME)
VALUES (dings, 3, 3,(preis*anzahl));

Stimmt, das ist wahrscheinlich die beste Loesung.

Es darf sich nur nie die Menge oder der Preis ändern.
m.

yrow · 10. November 2019 um 16:55

Ich würde die Trigger vermeiden…

Warum berechnest du den Wert nicht gleich beim Einfügen, du
machst ja das Insert auch selbst ?

—> INSERT INTO table (Artikel, Preis, Anzahl, SUMME)
VALUES (dings, 3, 3,(preis*anzahl));

da kann man geteilter Meinung sein. ich persönlich denke wenn er unbedingt den Preis in der DB gespeichert haben möchte, dann soll es auch das DB-System berechnen, denn die Performance ist meistens besser (Ok, bei diesem primitiven Fall ware es egal). *ZuOracleUndCoSchau*

ein weiterer wichtiger Azpekt ist, das alle Validierungen die mit dem DB-System gemacht werden können (in diesem Fall richtige Preisberechn.) sollen auch in der DB sein und nicht in der Anwendung. Warum das Ganze…weil…DB´s sind optimiert Daten korrekt in der DB vorzuhalten/verwalten, warum also warum sollte man selber was basteln wenn es die DB´s genauso gut evtl. besser können? Damit bleibt der ProgrammCode der Anwendung schlanker und besser Wart/Pflegbarer.

wobei man in diesem Fall Fragen muss, warum überhaupt der Preis gespeichert wird? Der Preis ist eine berechenbare Größe *ZuNormalisierungsformenSchau* *zwinker*

yrow · 10. November 2019 um 16:55

Stimmt, das ist wahrscheinlich die beste Loesung.

Es darf sich nur nie die Menge oder der Preis ändern.

*HiHi* *ROFL*

back to topic:
Bleibt doch bei einen Trigger, damit kann man alle Bereiche abdecken
ich habe mal grob aus dem Kopf ein Beispiel geschrieben so in der Art müsse es gehen. wenn nicht einfach melden und dann werde ich mir mal mehr mühe geben und es richtig testen usw.

CREATE OR REPLACE TRIGGER Preisberechnung
BEFORE INSERT OR UPDATE ON MeineTabelle
FOR EACH ROW

BEGIN
 :NEW.gesamtPreis := :NEW.preis \* :NEW.Anzal;
END;

Ulrich_Vaid · 10. November 2019 um 16:56

Ich würde die Trigger vermeiden…

Warum berechnest du den Wert nicht gleich beim Einfügen, du
machst ja das Insert auch selbst ?

—> INSERT INTO table (Artikel, Preis, Anzahl, SUMME)
VALUES (dings, 3, 3,(preis*anzahl));

da kann man geteilter Meinung sein. ich persönlich denke wenn
er unbedingt den Preis in der DB gespeichert haben möchte,
dann soll es auch das DB-System berechnen, denn die
Performance ist meistens besser (Ok, bei diesem primitiven
Fall ware es egal). *ZuOracleUndCoSchau*

–> Ja, da bin ich genau deiner Meinung…Der Poster hat allerdings niergends vermerkt, in welcher Schicht seine DB-Logik verpackt ist, ich kapsle solche Sache (in der Regel ) in Packages auf der DB…

ein weiterer wichtiger Azpekt ist, das alle Validierungen die
mit dem DB-System gemacht werden können (in diesem Fall
richtige Preisberechn.) sollen auch in der DB sein und nicht
in der Anwendung. Warum das Ganze…weil…DB´s sind optimiert
Daten korrekt in der DB vorzuhalten/verwalten, warum also
warum sollte man selber was basteln wenn es die DB´s genauso
gut evtl. besser können? Damit bleibt der ProgrammCode der
Anwendung schlanker und besser Wart/Pflegbarer.

–> Siehe oben…Ob Trigger allerding unter "Besser Wart/Pflegbar* fallen, möchte ich stark bezweifeln…ich versuche „versteckte“ Logik in Triggerh, welche irgendwie „Magic,Magic“ ablaufen, zu vermeiden

wobei man in diesem Fall Fragen muss, warum überhaupt der
Preis gespeichert wird? Der Preis ist eine berechenbare Größe
*ZuNormalisierungsformenSchau* *zwinker*

Ja, sicher, aber eben, dass war nun mal die Frage des OP. Oftmals müssen aber soche Berechnungen persistent abgelegt werden, wenn Historisierungen und Vergleiche / Analysen etc darauf ablaufen sollen…

Gruss

Tomh · 10. November 2019 um 16:56

Hi!

Ich würde die Trigger vermeiden…

Ich nicht.

Warum berechnest du den Wert nicht gleich beim Einfügen, du
machst ja das Insert auch selbst ?

—> INSERT INTO table (Artikel, Preis, Anzahl, SUMME)
VALUES (dings, 3, 3,(preis*anzahl));

Eine Möglichkeit - aber was ist bei einem Update? Warum muß ich mir beim Manipulieren von Datensätzen auch noch Gedanken darüber machen, was noch alles in die DB gehört?

Mit einem Trigger „erschlage“ ich all diese Sachen, befülle diverse „Default“-Felder (Manipulationsuser, Datumswerte, … schließlich will man ja wissen, welcher User den Mist gebaut hat bzw. welche anderen User dadurch welche Rechte an diesem Datensatz besitzen, etc.

Dazu noch der Algorithmus dieses Beispiels: Ich muß mir beim Einfügen oder Ändern (hie und da auch beim Löschen von abhängigen Werten in verknüpften Tabellen) keine Gedanken mehr machen, was ich wie noch berücksichtigen muß - was nicht bedeutet, dass ich mir keine Gedanken machen darf, was die Manipulation für Auswirkungen auf die gesamte DB haben könnte!

Grüße,
Tomh, ein Verfechter von Tabellen-Triggern (und: Ja, ich gebe zu, ich verfluche sie auch oft genug