Я видел десятичное число вместо int / long в различных примерах.Я просто пытаюсь понять, почему
Это возможно потому, что .NET decimal и Oracle NUMBER отображаются немного лучше , чем long и NUMBER, и этотакже дает вам больше гибкости.Если на более позднем этапе вы добавите scale в столбец 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 для удлиненных) значащих цифр
Oracle
NUMBER по умолчанию до 38 значащих цифр и шкала 0 (целое число).
Тип: NUMBER
Диапазон: + - 1 x 10 ^ -130 до 9.99 ... 9 x 10 ^ 125
Точность: 38 значащих цифр
Microsoft знает об этой проблеме и примечания
Этот тип данных является псевдонимом для типа данных NUMBER (38) и предназначен длячто OracleDataReader возвращает System.Decimal или OracleNumbeг вместо целочисленного значения.Использование типа данных .NET Framework может вызвать переполнение.
Если подумать, вам действительно нужно BigInteger, чтобы иметь возможность представлять такое же количество значащих цифр, что ик чему NUMBER по умолчанию.Я никогда не видел, чтобы кто-то делал это, и я полагаю, что это очень редкая необходимость.Кроме того, BigInteger все равно не поможет, поскольку NUMBER может иметь положительную и отрицательную бесконечность.