Ich mache eine einfache Inventaranwendung. In einer Tabelle habe ich Spalten Quantity, Price und TotalPrice. Was ist besser, machen TotalPrice ein Computed Column als Menge * Preis oder machen Sie diese Berechnung in meiner Anwendung und speichern Sie sie in TotalPrice?Berechnete Spalte für einfache Multiplikation?
Eine Regel in Datenbank-Design ist (in der Regel): speichert keine Informationen, die auch leicht abgerufen werden können.
In Ihrem Fall würde ich keine berechnete Spalte erstellen, aber die Multiplikation während des Abrufs. Entweder indem Sie direkt price * quantity auswählen oder indem Sie eine Ansicht erstellen, die diese Berechnung enthält.
Die Ansicht hat den zusätzlichen Vorteil, dass Sie die Formel leicht ändern können (z. B. einschließlich Mehrwertsteuer), ohne dass Sie alle Anweisungen in Ihrer Anwendung ändern müssen.
warum eine berechnete Spalte speichern, wenn Sie die Berechnungen in der Abfrage ausführen können?
SELECT (Quantity * Price) as TotalPrice FROM my_table
Um zu protokollieren. – SMUsamaShah
Und wenn TotalPrice geändert wird, und erfordert Steuer. Dann müssen Sie nur an einem Ort ändern, nicht jede Abfrage – PostMan
Wenn Sie den Preis oder die Menge aktualisieren, werden Sie gezwungen, ein 2cd Update auf TotalPrice durchzuführen. Was passiert, wenn ein anderer Entwickler das 2cd Update vergisst? Jetzt haben Sie schlechte Daten.
Sie könnten einen Trigger synchron halten, aber die Möglichkeit für fehlerhafte Daten besteht weiterhin. In einigen RDMS werden die Trigger nicht für jede Zeile ausgelöst, die in einem Set-basierten Update aktualisiert wird.
Aber manchmal ist es erforderlich, berechnete Felder zu speichern. Wenn die Tabelle groß ist und Sie das berechnete Feld durchsuchen möchten. (Sie müssen die Daten speichern, um sie zu indizieren). In einigen Designs speichern Sie nicht nur die berechneten Felder, sondern auch aggregierte Berechnungen.
Es ist nicht immer falsch, berechnete Felder zu speichern, stellen Sie nur sicher, dass Sie die Kompromisse kennen.
* EDIT * Ein weiterer Punkt. Wenn Sie "Amount_Paid" berechnen, geht der tatsächliche vom Kunden gezahlte Betrag verloren, wenn Sie die Berechnungsformel ändern.
Design, um das Problem zu lösen. Wenn das bedeutet, eine Faustregel zu brechen, brechen Sie ein paar Daumen. * ENDE BEARBEITEN *
Ich würde nur hinzufügen, dass es falsch wäre, eine Spalte zu speichern, die berechnet werden könnte, ohne eine CHECK() - Einschränkung für diese Spalte zu haben, um sicherzustellen, dass die Dinge immer summiert sind. –
Also sollte ich eine Ansicht hinzufügen? – SMUsamaShah
Es zentralisiert die Definition dieser (zugegebenermaßen einfachen) Berechnung. Wenn nur zum Abrufen verwendet (z. B. Berichte), würde ich für die Ansicht gehen. Abhängig von Ihrem DBMS und Ihrer Programmiersprache kann es jedoch zu Problemen kommen, wenn Sie versuchen, die Daten über die Ansicht zu aktualisieren. Wenn das der Fall ist, würde ich die Multiplikation der SELECT-Anweisung hinzufügen oder einfach in der Anwendung tun. Es hängt von Ihrer Umgebung ab. Es gibt keine "goldene Regel" dafür. –
Ein Blick klingt gut. Wenn sich die "TotalPrice" -Berechnung in Zukunft ändert, ändern Sie nur die Ansicht und nicht 500 Abfragen. Oder Sie könnten eine Funktion in Ihren Abfragen für denselben Effekt aufrufen. –