Sembra come Money tipo è sconsigliato come descritto herePostgreSQL: quale tipo di dati deve essere utilizzato per la valuta?
La mia applicazione ha la necessità di immagazzinare moneta, che tipo di dati devo usare? Numerico, denaro o FLOAT?
Numeric con precisione forzata di 2 unità. Non utilizzare mai float o float come datatype per rappresentare la valuta, perché se lo fai, le persone saranno infelici quando la cifra del bilancio inferiore del report finanziario è errata di + o - pochi dollari.
Il tipo di denaro è stato appena lasciato per ragioni storiche per quanto posso dire.
Non è questo il motivo per cui si evita il virgola mobile. Anche Numeric avrà errori di arrotondamento se dividi per qualcosa che non si divide in una potenza di dieci, indipendentemente dalla precisione che usi. (La precisione di 2 è comunque una cattiva idea ... controlla i documenti.) – Doradus
Le scelte sono:
integer: conservare l'importo in centesimi. Questo è quello che usano le transazioni EFTPOS.decimal(12,2): memorizza l'importo con esattamente due posizioni decimali. Questo è quello che usa il software di contabilità generale.float: idea terribile - precisione inadeguata. Questo è ciò che usano gli sviluppatori ingenui.L'opzione 2 è la più comune e più semplice da utilizzare. Rendi la precisione (12 nel mio esempio, che significa 12 cifre in tutto) come grande o piccola come funziona meglio per te.
Si noti che se si aggregano più transazioni che erano il risultato di un calcolo (ad esempio un tasso di cambio) in un singolo valore che ha un significato aziendale, la precisione dovrebbe essere maggiore per fornire un valore macro accurato; considera l'utilizzo di qualcosa come decimal(18, 8) quindi la somma è accurata e i singoli valori possono essere arrotondati alla precisione di un centesimo per la visualizzazione.
Se stai lavorando con qualsiasi tipo di calcolo della tassa inversa o di cambio, hai bisogno di almeno 4 cifre decimali, o perderai i dati. Quindi 'numerico (15,4)' o 'numerico (15,6)' è una buona idea. –
Esiste una quarta opzione, ovvero utilizzare una stringa e utilizzare un tipo decimale non lossy equivalente nella lingua dell'host. – ioquatix
La tua fonte non è in alcun modo ufficiale. Risale al 2011 e non riconosco nemmeno gli autori. Se il tipo di denaro è stato "scoraggiato", PostgreSQL lo direbbe nel manuale - which it doesn't.
Per una fonte più ufficiale, leggere this thread in pgsql-general (from just this week!), con le dichiarazioni da parte degli sviluppatori di base tra cui D'Arcy JM Cain (autore originale del tipo di soldi) e Tom Lane
In sostanza, money ha la sua (limitata) utilizza. Il vantaggio rispetto a numeric è prestazioni.
decimal è solo uno pseudonimo per numeric in Postgres.
risposta correlati (e commenti!) Su miglioramenti nelle versioni più recenti:
Personalmente, mi piace di memorizzare valuta come integer centesimi che rappresentano. È più efficiente di qualsiasi altra delle opzioni menzionate.
Ci sono diverse discussioni sulle mailing list che danno l'impressione che il tipo di denaro non sia almeno raccomandato, ad esempio: qui: http://postgresql.nabble.com/Money-type-todos-td1964190.html#a1964192 plus per essere onesti: il manuale per la versione 8.2 ** lo ha fatto ** chiamandolo deprecato: http://www.postgresql.org/docs/8.2/static/datatype-money.html –
@a_horse_with_no_name: il tuo link è a un thread da 2007, che è anche quando 8.2 era la versione corrente e il tipo 'money' era, infatti, deprecato. I problemi sono stati risolti e il tipo è stato aggiunto nelle versioni successive. Personalmente mi piace memorizzare la valuta come 'integer' che rappresenta Cents. –
Erwin, potresti essere corretto dal punto di vista del database da solo. Tuttavia, se si combina Postgresql + Java, NON è affatto buono (dalla mia esperienza). Leggendo il tuo commento, ho usato DENARO per la maggior parte dei miei campi di valuta e ora ottengo questa eccezione Java: "SQLException si è verificato: org.postgresql.util.PSQLException: valore errato per tipo double: 2.500.00 **". Ho cercato su Google e non ho trovato una buona soluzione, quindi sono nel compito noioso di cambiarli tutti in NUMERICO o DECIMALE ora !!! –
io continuo tutti i miei campi monetari come:
numeric(15,6)
sembra eccessivo avere che molte cifre decimali, ma se c'è anche la minima possibilità che si dovranno fare i conti con più valute Avrete serve tanta precisione per la conversione. Non importa cosa sto presentando un utente, lo memorizzo sempre in dollari USA. In questo modo posso facilmente convertire in qualsiasi altra valuta, dato il tasso di conversione per il giorno in questione.
Se non si fa mai nulla tranne una valuta, la cosa peggiore qui è che hai sprecato un po 'di spazio per memorizzare alcuni zeri.
Questo ha il rischio di risultati errati a causa della mancanza di troncamento. Se i valori diversi da zero perdono involontariamente nei decimali rimanenti, ad esempio un campo di prezzo contenente 0,333333 dollari, è possibile che si verifichi una situazione in cui il sistema mostra il risultato dell'acquisto di 3 articoli a $ 0,33 ciascuno, per un totale di $ 1 invece di $ 0,99. – Peteris
Perteris, quindi cosa suggerisci invece? Non importa quanto precisione passi a questo rounding può essere un problema. Semplicemente non ho trovato un modo migliore, anche se questo non è l'ideale. –
Punto fisso e troncato laddove appropriato. Non appena raggiungi un valore monetario "memorizzabile", ad es. un prezzo offerto a un cliente, dovrebbe essere in metriche appropriate, che nella maggior parte dei casi sarebbero in centesimi nel normale ambiente di vendita al dettaglio. Se hai esigenze aziendali diverse (ad es.prezzo di merci ad alto volume per unità) potrebbe esserci una diversa impostazione di accuratezza, ma è necessario trattare la presentazione * insieme allo spazio di archiviazione * - se si visualizza il numero di denaro con x decimali (o viceversa, ad esempio in migliaia intere) allora è necessario anche memorizzarlo con * quella * precisione, non meno, ma anche non più. – Peteris
Se avete letto l'intero thread, Numeric è la strada da percorrere. – razpeitia