Jeg har set decimal brugt i stedet for int/long i forskellige eksempler. Jeg prøver bare at forstå hvorfor
Det er sandsynligvis fordi .NET decimal og Oracle NUMBER kort en smule bedre end long og NUMBER og det giver dig også mere fleksibilitet. Hvis du på et senere tidspunkt tilføjer en skala i Oracle-kolonnen, så behøver du ikke ændre datatype, hvis du allerede har brugt decimal .
decimal er bestemt langsommere end int og long da de to senere understøttes i hardware. Når det er sagt, skal du smadre nogle seriøse mængder data, for at det kan gøre nogen forskel. Jeg synes stadig, at du skal bruge long hvis det er det, du har med at gøre, og så bør du også lade tabelkolonnedefinitionerne repræsentere det. NUMBER(18,0) i long og så videre.
Årsagen decimal kort, lidt bedre er det long er 64 bit og decimal er (en slags) 128 bit.
.NET
Type:decimal
Omtrentlig område:±1,0 × 10^−28 til ±7,9 × 10^28
Nøjagtighed:28-29 signifikante cifre
Type:lang
Interval:–9.223.372.036.854.775.808 til 9.223.372.036.854.775.807
Nøjagtighed:18 (19 for lange) signifikante cifre
Oracle
NUMBER standard til 38 signifikante cifre og skala 0 (heltal).
Indtast:NUMBER
Interval:+- 1 x 10^-130 til 9,99...9 x 10^125
Nøjagtighed:38 signifikante cifre
Microsoft er opmærksom på problemet og noterer det
Denne datatype er et alias for datatypen NUMBER(38) og er designet således, at OracleDataReader returnerer et System.Decimal eller OracleNumber i stedet for en heltalsværdi. Brug af .NETFramework-datatypen kan forårsage et overløb.
Når du tænker over det, har du faktisk brug for BigInteger at være i stand til at repræsentere det samme antal signifikante cifre i forhold til hvilket NUMBER standard til. Jeg har aldrig set nogen gøre det, og jeg vil antage, at det er et meget sjældent behov. Også BigInteger ville stadig ikke klippe det siden NUMBER kan være af positiv og negativ uendelighed.