È giusto mantenere una proprietà calcolata nel DB?

Question

È giusto mantenere una proprietà calcolata nel DB?

#1 da (5 voti)
#2 da (1 voti)

5

Vorrei sapere cosa ne pensi di mantenere una "proprietà autocomputed" al database. Ad esempio, ho queste proprietà

decimal Price {get;set;}
decimal Tax {get;set;}
decimal PriceWithTax {get {return Price + Tax;}}

Penso di aver bisogno di persist PriceWithTax . Posso usare questa colonna, ad esempio, nelle viste DB. Ma sento che questa soluzione può portare a bug nascosti. Cosa ne pensi?

Modifica: Ok, provo a spiegare il nostro vero problema. Abbiamo un "Ordine" di classe che ha una collezione di oggetti - Item Item di classe. Class ItemOrder ha property Prezzo e classe Order has property TotalPrice. E implementazione di TotalPrice:

TotalPrice {get { return ItemOrders.Sum(i => i.Price); }}

E abbiamo bisogno di ordinare, raggruppare nel database. Quindi non è una regola di bussiness ma una "regola dei dati".

design database-design

posta Marek 16.03.2014 - 19:06

fonte

2 risposte

1

Le colonne calcolate non aggiungono nulla ai tuoi dati e interrompono il principale di DRY - stai ripetendo i tuoi dati.

Se vuoi utilizzare la colonna calcolata per le tue visualizzazioni, AFAIK, la maggior parte dei database oggi supporta colonne calcolate nelle tue viste (nel senso che tu definisci la colonna nella tua vista come Tax + Price ).

L'unica ragione per cui posso pensare che sarebbe necessario salvare i dati calcolati è se il calcolo non è banale e consuma tempo / cpu / memoria, nel qual caso il calcolo su insert ti libererà dal fare il calcolo e di nuovo.

Un altro motivo potrebbe essere la possibilità di creare un indice sulla colonna calcolata per una facile ricerca. Oggi la maggior parte dei database supporta anche alcuni indici basati su funzioni , che saranno superiori soluzione.

risposta data 16.03.2014 - 19:52

fonte

Leggi altre domande sui tag design database-design

Utilizzo di metodi astratti per forzare le sottoclassi per definire i valori per i campi membri Precisione di "algoritmi calcolatori"

score 5 · Accepted Answer

La prima domanda che dovresti porci è se si tratta di una regola aziendale o qualcosa di puramente correlato ai dati .

Ad esempio, le tasse che una persona dovrebbe pagare ogni anno dipende da più regole aziendali complesse. Queste regole sono soggette a frequenti cambiamenti, quindi non è saggio creare una colonna calcolata contenente tali informazioni. D'altra parte, un giorno e un mese di nascita della persona estratta dalla data di nascita completa non dipende dalle regole aziendali, ed è molto improbabile che cambi durante la vita della domanda; quindi, creare una colonna calcolata per quello sembra a posto.

Nel tuo esempio, è difficile dirlo con certezza, senza un contesto aggiuntivo, ma suppongo che il prezzo con le imposte sia una regola aziendale. Cosa accadrebbe se ci fossero clienti che non dovrebbero pagare una tassa? E se la tassa fosse diversa da caso a caso?

La seconda domanda da porre è se l'archiviazione della colonna calcolata avvantaggerà la tua applicazione . Nel mio precedente esempio con la data di nascita, potrebbe essere opportuno archiviare queste informazioni aggiuntive in un contesto in cui dovresti cercare frequentemente le persone in base al loro giorno e mese di nascita, indipendentemente dall'anno di nascita.

Nel tuo caso, se il prezzo con tasse è semplice come l'aggiunta di prezzo e tasse, perché creare una colonna aggiuntiva? Come renderebbe più semplice o più veloce la tua applicazione?