V různých příkladech jsem viděl místo int/long použito desítkové. Jen se snažím pochopit proč
To je pravděpodobně proto, že .NET decimal a Oracle NUMBER mapuje o něco lépe než long a NUMBER a také vám dává větší flexibilitu. Pokud v pozdější fázi přidáte měřítko ve sloupci Oracle, pak byste nemuseli měnit datový typ, pokud jste již použili decimal .
decimal je jistě pomalejší než int a long protože poslední dva jsou podporovány v hardwaru. To znamená, že k tomu, aby se něco změnilo, musíte shromáždit nějaké vážné množství dat. Stále si myslím, že byste měli používat long pokud to je to, s čím máte co do činění, pak byste to měli také nechat reprezentovat definice sloupců tabulky. NUMBER(18,0) pro long a tak dále.
Důvod decimal mapy o něco lepší je, že long je 64 bitů a decimal je (tak trochu) 128 bitů.
.NET
Typ:desítkové
Přibližný rozsah:±1,0 × 10^−28 až ±7,9 × 10^28
Přesnost:28–29 platných číslicTyp:dlouhý
Rozsah:–9,223,372,036,854,775,808 až 9,223,372,036,854,775,807
Přesnost:18 (19 pro dlouhé) platné číslice
Oracle
NUMBER výchozí hodnota je 38 platných číslic a měřítko 0 (celé číslo).
Typ:NUMBER
Rozsah:+- 1 x 10^-130 až 9,99...9 x 10^125
Přesnost:38 platných číslic
Microsoft si je tohoto problému vědom a poznamenává
Tento datový typ je alias pro datový typ NUMBER(38) a je navržen tak, že OracleDataReader vrací System.Decimal nebo OracleNumber místo celočíselné hodnoty. Použití datového typu .NETFramework může způsobit přetečení.
Když se nad tím zamyslím, skutečně potřebujete BigInteger být schopen reprezentovat stejný počet platných číslic jako NUMBER výchozí na. Nikdy jsem nikoho neviděl dělat to a předpokládám, že je to velmi vzácná potřeba. Také BigInteger stále by to nepřerušilo od NUMBER může mít kladné a záporné nekonečno.