Виждал съм да се използва десетичен вместо int/long в различни примери. Просто се опитвам да разбера защо
Това вероятно е защото .NET decimal и Oracle NUMBER карти малко по-добре от long и NUMBER и също така ви дава повече гъвкавост. Ако на по-късен етап добавете скала в колоната на Oracle, тогава не би трябвало да променяте типа данни, ако вече сте използвали decimal .
decimal със сигурност е по-бавен от int и long тъй като последните две се поддържат хардуерно. Това каза, че трябва да счупите сериозно количество данни, за да има някаква разлика. Все още мисля, че трябва да използвате long ако това е, с което се занимавате и тогава трябва също да оставите дефинициите на колоните на таблицата да представят това. NUMBER(18,0) за long и така нататък.
Причината decimal карти малко по-добре е, че long е 64 бита и decimal е (вид) 128 бита.
.NET
Тип:десетичен
Приблизителен диапазон:±1,0 × 10^−28 до ±7,9 × 10^28
Прецизност:28-29 значими цифриТип:дълго
Обхват:–9,223,372,036,854,775,808 до 9,223,372,036,854,775,807
Прецизност:18 (19 за дълги) значими цифри
Оракул
NUMBER по подразбиране е 38 значими цифри и мащаб 0 (цяло число).
Въведете:NUMBER
Обхват:+- 1 x 10^-130 до 9,99...9 x 10^125
Прецизност:38 значими цифри
Microsoft е наясно с проблема и отбелязва
Този тип данни е псевдоним за типа данни NUMBER(38) и е проектиран така, че OracleDataReader да връща aSystem.Decimal или OracleNumber вместо целочислена стойност. Използването на типа данни .NETFramework може да причини преливане.
Като се замисля, всъщност се нуждаете от BigInteger за да можете да представите същия брой значими цифри като това, което NUMBER по подразбиране. Никога не съм виждал някой да прави това и предполагам, че това е много рядка нужда. Също така BigInteger все още не би го отрязал от NUMBER може да бъде с положителна и отрицателна безкрайност.
