Pavel heeft helemaal gelijk, ik wil het graag even uitleggen.
Ervan uitgaande dat u een prestatie-impact bedoelt in vergelijking met floating point, of fixed-point-offset integer (d.w.z. duizendsten van een cent opslaan als een geheel getal):Ja, er is een grote prestatie-impact. PostgreSQL, en door de geluiden van dingen MySQL, sla DECIMAL op / NUMERIC in binair gecodeerde decimalen. Dit formaat is compacter dan het opslaan van de cijfers als tekst, maar het is nog steeds niet erg efficiënt om mee te werken.
Als u niet veel berekeningen in de database uitvoert, is de impact beperkt tot de grotere opslagruimte die nodig is voor BCD in vergelijking met integer of drijvende komma, en dus de bredere rijen en langzamere scans, grotere indexen, enz. Vergelijkingsbewerkingen in b -tree index zoekopdrachten zijn ook langzamer, maar niet genoeg om uit te maken, tenzij je al CPU-gebonden bent om een andere reden.
Als je veel berekeningen doet met de DECIMAL / NUMERIC waarden in de database, dan kunnen de prestaties er echt onder lijden. Dit is vooral merkbaar, althans in PostgreSQL, omdat Pg niet meer dan één CPU kan gebruiken voor een bepaalde vraag. Als je een enorme hoeveelheid delen en vermenigvuldigen, complexere wiskunde, aggregatie, enz. op numeriek doet, kun je beginnen te merken dat je CPU-gebonden bent in situaties waar je nooit zou zijn bij het gebruik van een float- of integer-gegevenstype. Dit is vooral merkbaar in OLAP-achtige (analyse) workloads, en in rapportage of datatransformatie tijdens laden of extraheren (ETL).
Ondanks het feit dat er is een prestatie-impact (die varieert op basis van de werklast van verwaarloosbaar tot vrij groot) moet u over het algemeen numeric gebruiken / decimal wanneer dit het meest geschikte type is voor uw taak - d.w.z. wanneer zeer hoge bereikwaarden moeten worden opgeslagen en/of afrondingsfouten niet acceptabel zijn.
Af en toe is het de moeite waard om een bigint en fixed-point offset te gebruiken, maar dat is onhandig en inflexibel. In plaats daarvan drijvende-komma gebruiken is zelden het juiste antwoord vanwege alle uitdagingen om betrouwbaar te werken met drijvende-kommawaarden voor zaken als valuta.
(Trouwens, ik ben heel enthousiast dat sommige nieuwe Intel-CPU's en IBM's Power 7-reeks CPU's hardware-ondersteuning bieden voor IEEE 754 decimale drijvende komma. Als dit ooit beschikbaar komt in lagere CPU's, zal dit een enorme overwinning zijn voor databases .)