Widziałem dziesiętne używane zamiast int/long w różnych przykładach. Próbuję tylko zrozumieć, dlaczego
Dzieje się tak prawdopodobnie dlatego, że .NET decimal i Oracle NUMBER mapuje trochę lepiej niż long i NUMBER a także zapewnia większą elastyczność. Jeśli na późniejszym etapie dodasz wagę w kolumnie Oracle, nie musisz zmieniać typu danych, jeśli już użyłeś decimal .
decimal jest z pewnością wolniejszy niż int i long ponieważ dwa ostatnie są obsługiwane sprzętowo. To powiedziawszy, musisz przetworzyć poważną ilość danych, aby miało to jakiekolwiek znaczenie. Nadal uważam, że powinieneś używać long jeśli to jest to, z czym masz do czynienia, a następnie powinieneś również pozwolić, aby reprezentowały to definicje kolumn tabeli. NUMBER(18,0) dla long i tak dalej.
Powód decimal mapy trochę lepsze to long to 64 bity i decimal to (coś w rodzaju) 128 bitów.
.NET
Wpisz:dziesiętny
Przybliżony zakres:±1,0 × 10^−28 do ±7,9 × 10^28
Precyzja:28-29 cyfr znaczącychWpisz:długi
Zakres:–9 223 372 036 854 775 808 do 9 223 372 036 854 775 807
Dokładność:18 (19 dla ulong) cyfr znaczących
Wyrocznia
NUMBER domyślnie 38 cyfr znaczących i skala 0 (liczba całkowita).
Wpisz:NUMBER
Zakres:+- 1 x 10^-130 do 9,99...9 x 10^125
Precyzja:38 cyfr znaczących
Microsoft zdaje sobie sprawę z problemu i zauważa
Ten typ danych jest aliasem dla typu danychNUMBER(38) i został zaprojektowany tak, aby OracleDataReader zwracał aSystem.Decimal lub OracleNumber zamiast wartości całkowitej. Użycie typu danych .NETFramework może spowodować przepełnienie.
Pomyśl o tym, że faktycznie potrzebujesz BigInteger aby móc reprezentować tę samą liczbę cyfr znaczących, co NUMBER domyślnie. Nigdy nie widziałem, żeby ktoś to robił i przypuszczam, że to bardzo rzadka potrzeba. Również BigInteger nadal nie wycinałby go, ponieważ NUMBER może mieć nieskończoność dodatnią i ujemną.
