Ich persönlich halte nix von "in der Datenbank" rechnen. Es gibt aber auch Ausnahmen. Z.B. eine Preiserhöhung wo man den neuen Preis eintragen will. Da ist es einfacher den neuen Preis in der Datenbank per Befehl zu berechnen. Ich gehe dann so vor.
1
Feld preis in alten_preis umbenennen / bzw kopieren (Wegen Nachvollziehbarkeit)
2.) Feld preis anlegen (Nur bei umbenennen)
3.) Feld Preis neu berechnen
Das ganze geht mit 3 Befehlen und ist superschnell
Wenn man aber NUR die Daten aus nur einen Datensatz braucht beim Berechnen dann rechne ich per Programm jedes mal neu.
Was ich damit sagen will ist, es kommt immer auf Effizienz an und wichtig auf Nachvollziehbarkeit. Bei mein Beispiel z.b. weiß ich warum der neue_preis plötzlich diese Summe hat (alter_preis + Preiserhöhung). Und ich habe den Backup-Effekt (Preiserhöhung falsch ist egal, da ich den alten Preis als Backup habe)
Was dein Problem angeht, würde ich NIX in der Datenbank berechnen wenn es sich dabei um die Anzeige EINZELNER Datensätze handelt. Willst du aber Tabellen machen die schnell gescrollt werden sollen, kann es je nach Anzeigemodul durchaus sinnvoll sein diese (berechneten) Werte in der Datenbank abzulegen. Effizienz halt. Anzeigemodule sind keine guten Rechner, und Temporäre Datenbanken sind bei der Erstellung teilweise zeitintensiv.
Ich weiß das ich dir mit meinen Erklärungen nicht wirklich geholfen habe, aber ich hoffe dir klar zumachen wo der Grund für was liegt.
Mein persönlicher Tipp ist, versuch es ohne Zusatzfelder. Wenn es lahmt kannst du ja die Zusatzfelder immer noch anlegen und die Berechnungszeilen im Code löschen.
Und so nebenbei. Vergiss nicht das SQL-Datenbanken nicht gerade klein sind.
Gruß
Pucki