Le migliori pratiche quando si tratta e si memorizzano i dati calcolati

Per i dati così semplici da calcolare, non ha senso memorizzare dati denormalizzati (tutti e tre).

Archivia solo i grammi e l'utente nel database, quindi carica le proprietà dell'utente e grammi di questo oggetto con i dati memorizzati.

public class Weight
{
     public string User {get;set;}
     public double Grams {get;set;}
     public double KG 
     {
         get { return Grams * .001; }
         set { Grams = value * 1000.0;}
     }
     public double Pounds
     { 
         get { return Grams * 0.00220462; }
         set { Grams = value * 453.592; }
     }
}

e per lo storage, possiamo vedere i vantaggi del pattern di repository per casi come questo in cui la nostra soluzione di archiviazione ottimale non assomiglia al nostro caso di utilizzo aziendale:

public class WeightRepository
{
      public void Insert(Weight weight)
      {
          sqlConnection.Execute("insert into Weight (User, Grams) values (@user, @grams)", weight.User, weight.Grams);
      }

      //Get, update, ect
}

Con questo approccio, la nostra logica aziendale (classe di peso) è isolata, comoda da usare e facilmente testata da unità.

Possiamo anche ottenere letture veloci e brillanti dal nostro DB poiché abbiamo ridotto al minimo il nostro numero di colonne.

Di solito, una buona architettura aumenta le prestazioni, non la ostacola:)

Dipende!

Se possibile, proverei sempre a memorizzare tutto nel database nella stessa unità. Rende più facile il confronto, la ricerca e molte altre cose ("Trovami tutti i widget oltre 1 kg").

Tuttavia, sono stato anche in situazioni in cui è importante che l'utente abbia sempre restituito esattamente gli stessi dati immessi - se hanno inserito 1.00.000437546535 lb, vogliono indietro 1.00000437546535 lb, non 1.0000043754653 6 lb come potrebbe accadere se convertite in kg e viceversa. In tal caso, è necessario memorizzare il modulo originale nel database e convertirlo secondo necessità.

Dipende

Se la tua tabella è normalizzata (in particolare se è intesa per essere in terza forma normale , BCNF o superiore), quindi ogni colonna deve essere un attributo della chiave, non un attributo di qualcos'altro.

Diciamo che la tabella è destinata a rappresentare un insieme di misure, in cui ogni misura è una riga. Il valore inserito dall'utente è un attributo della misura. I valori calcolati da quel valore non lo sono; sono attributi del valore, che a sua volta è un attributo della misurazione. Pertanto, l'archiviazione di tali valori violerebbe 3NF.

Se utilizzi una tabella denormalizzata potresti prendere in considerazione il pre-calcolo di tali valori e memorizzandoli in colonne separate. Non solo questo potrebbe ridurre il tempo di calcolo se hai ancora bisogno di quei valori di nuovo, ma la loro memorizzazione ti permetterebbe anche di indicizzare i valori, ad es. se dovessi ordinare o cercare non dai dati inseriti ma dal risultato del calcolo.

Colonne calcolate. SQL Server ha anche una bella funzionalità chiamata Colonne calcolate , che possono essere indicizzato anche . Quindi, supponendo che tu possa eseguire il calcolo in T-SQL, potresti aggiungere i valori come colonne calcolate, che appariranno come normali colonne ma non occuperanno spazio di archiviazione.

Nel tuo caso , non memorizzerei i valori calcolati. Se dovevo essere in grado di cercare nella tabella il risultato del calcolo, potrei considerare l'aggiunta di una colonna calcolata e un indice su quello.