Ich kann Jelly nur zustimmen. Das ganze Vorhaben kommt mir auch recht seltsam vor.
Du darfst auf keinen Fall die Programmlogik zugunsten der Performance reduzieren. Ich glaube aber zu wissen, was du willst. Bei mir sieht es so aus, daß ich einen Rechnungsendbetrag an vielen Stellen brauche. Nun besteht aber jede Rechnung aus vielen Positionen. Natürlich könnte ich den Endbetrag immer wieder aus den Positionen errechnen lassen.
Aber irgendwo hörts dann aber doch auf. 8) Ich speichere das ganze lieber in einer zweiten Tabelle "Rechnungskopf". Also eine 1:n Beziehung, wo jede Rechnung eben n Positionen hat. Jelly hat in der Theorie schon recht. Angenommen ich muß eine Rechnungsposition nachträglich löschen, weil sich rausstellt, daß die Ware doch nicht da ist. In diesen Fällen genügt es dann nicht mehr, nur die Position zu löschen. Ich muß auch ein Update für die Endsumme machen. Aber das weiß ich ja vorher und muß es eben auch machen. Die Konsistenz der Datenbank ist bei so was auch nicht in Gefahr, sofern man seine Transaktionen sinnvoll plant.
Was Du vor hast, das ist allerdings so, als würde ich versuchen die Endsumme in der Rechnungs-Positionen Table unterzubringen. In welchem Feld denn ? Soll ich das
Einzelpreis_oder_Summe_oder_Durchschnitt_Feld
nennen ?
Und später selber nicht mehr wissen, um was es sich jetzt überhaupt handelt ? 8)