Questo può essere complicato perché la conversione ripetuta tra le unità può accumulare errori di arrotondamento.

Ad esempio, l'inserimento di un valore in metri, la conversione in piedi e il ritorno in metri potrebbero mostrare un lieve errore, ad esempio 1 metro e 0,9999 metri. Oppure, per un esempio meno ovvio, 4.587 metri di conversione in piedi e schiena potrebbero dare 4.585 metri.

Più cambi valori, più inaccurati potrebbero essere. Poiché l'informatica spesso cerca di minimizzare il caso peggiore, dobbiamo assumere il peggio per mostrare che il valore non può mai deviare più di un certo importo.

Per raggiungere questo obiettivo, devi sempre memorizzare il valore nel modo più preciso possibile e convertire al volo secondo necessità e mai più di una volta .

Vorrei memorizzare amount e unit campi che rappresentano per es. "4,5 metri" e sempre lo usano come base. Se ho bisogno di piedi, convertilo in piedi: se ho bisogno di miglia, converti i metri in miglia, non i metri in piedi in miglia.

L'approccio due potrebbe essere più intensivo a livello di elaborazione a lungo termine, ma è più accurato. Dato che questi calcoli non sono esattamente complessi o costosi per cominciare e che i computer moderni sono estremamente potenti, sacrificherei l'efficienza per la precisione.

Raccomando anche di impostare una tabella di conversione usando il più precisione possibile. Questo non cambierà mai a meno che non vengano aggiunte nuove unità, quindi una tabella statica e di alta precisione è una scommessa sicura e aiuterà a garantire coerenza e accuratezza.

Credo che il termine che stai cercando sia "unità di misura" in quanto trasmette più chiaramente il concetto di valore e una sorta di unità associate al valore.

E come stai iniziando a vedere, ci sono alcuni approcci per gestire le sfide che stai incontrando.

Per le operazioni di runtime, le soluzioni vanno dal semplice uso di unità "implicite", con le unità incorporate nel nome della variabile, con una proprietà separata per le unità, all'utilizzo di un oggetto o una classe che presenta come unità di misura effettiva ( ad es. valore e unità combinati). Qui c'è un compromesso tra il livello di sforzo da implementare, convertire e utilizzare contro i rischi di insuccesso all'interno del tuo codice.

Le operazioni di database sono un po 'più difficili da classificare, dato che la principale sfida è l'incapacità di rappresentare un'unità di misura effettiva. Ho visto soluzioni usando "unità e unità implicite associate al nome della colonna.

Ho anche visto usare una seconda colonna per rappresentare le unità. A seconda di come lo strutturate, quella colonna potrebbe essere una semplice rappresentazione di stringa o potrebbe essere un indice di chiave esterna in un'altra tabella fissa che indica il tipo di unità.

Per rispondere ad alcune delle tue domande -

La prima cosa che devi fare è valutare l'impatto che questo ha sulla tua base di codice. Se utilizzi molte unità e fai molte conversioni, probabilmente vorrai una soluzione più solida. Viceversa, se questo accade solo di tanto in tanto, potresti riuscire a farla franca con una soluzione più semplice.

Eviterei di eseguire molte conversioni inutili, se possibile. Come hai notato, introduce un errore che può generare calcoli. Generalmente, scegli il modulo più usato e usalo come "unità base" su cui lavorare. Ma mantieni quel consiglio basandoti sui dettagli di ciò che stai facendo e renditi conto che non devi seguire rigorosamente le regole di normalizzazione se semplifica la tua progettazione iniziale e la manutenzione a lungo termine.

Memorizza l'unità e il valore separatamente, non eseguire la conversione a meno che non sia necessario (ad esempio calcolare il peso per la spedizione, l'utente lo richiede, ecc.).

Non tutte le unità possono essere convertite da una all'altra

Considera un database per un negozio di alimentari. Tutti i prodotti che vendono hanno una misura specifica, ma non lo stesso tipo di misura.

• La maggior parte delle merci è etichettata per peso (2 libbre)
• I liquidi sono etichettati per volume (500 ml)
• Le pentole sono etichettate in lunghezza (9x9x3 pollici per una pentola jellyroll, ma 9 pollici di diametro per una padella)

Google non tenterà nemmeno di convertire tra unità di peso e volume (almeno non in modo generale, avresti bisogno di una tabella di conversione per ogni tipo di prodotto).

Gli utenti possono preferire un tipo di unità rispetto ad un altro in contesti specifici

Anche nei casi in cui tutte le unità possono essere convertite da una all'altra, ci sono molti casi in cui unità specifiche sono usuali per determinati tipi di dati. Per quantità minori, di solito è preferibile un'unità più piccola. Lo stesso vale per quantità maggiori e unità più grandi.

• Nel negozio di tessuti, comprerò tessuti dal metro (imperiale) o metro (metrico), ma mi aspetto che i miei pulsanti siano etichettati in frazioni di un pollice o millimetri (lo stesso è vero per il legname e le unghie a l'archivio hardware)
• Anche in paesi che sono completamente metrici o completamente imperiali, troverai casi limite come bottiglie da 2 litri di pop negli Stati Uniti o ricette in Canada che utilizzano tazze e cucchiai da tavola
• I banchi gastronomia qui in Canada di solito etichettano i loro prodotti di 100 grammi (immagino che l'ettogramma non sia mai stato catturato?) mentre altri prodotti all'interno dello stesso negozio misurati in peso useranno chilogrammi