He visto usar decimales en lugar de int/long en varios ejemplos. Solo estoy tratando de entender por qué
Probablemente se deba a que .NET decimal y Oracle NUMBER mapas un poco mejores que long y NUMBER y también te da más flexibilidad. Si en una etapa posterior agrega una escala en la columna Oracle, entonces no tendría que cambiar el tipo de datos si ya usó decimal .
decimal ciertamente es más lento que int y long ya que los dos últimos son compatibles con el hardware. Dicho esto, debe procesar una gran cantidad de datos para que marque la diferencia. Sigo pensando que deberías usar long si eso es con lo que está tratando, entonces también debe dejar que las definiciones de las columnas de la tabla representen eso. NUMBER(18,0) para long y así sucesivamente.
La razón decimal mapas un poco mejor es que long es de 64 bits y decimal es (más o menos) 128 bits.
.NET
Tipo:decimal
Rango aproximado:±1,0 × 10^−28 a ±7,9 × 10^28
Precisión:28-29 dígitos significativos
Tipo:largo
Rango:–9,223,372,036,854,775,808 a 9,223,372,036,854,775,807
Precisión:18 (19 para ulong) dígitos significativos
Oráculo
NUMBER el valor predeterminado es 38 dígitos significativos y escala 0 (entero).
Tipo:NUMERO
Rango:+- 1 x 10^-130 a 9,99...9 x 10^125
Precisión:38 dígitos significativos
Microsoft es consciente del problema y toma nota
Este tipo de datos es un alias para el tipo de datos NÚMERO(38) y está diseñado para que OracleDataReader devuelva un System.Decimal u OracleNumber en lugar de un valor entero. Usar el tipo de datos .NETFramework puede causar un desbordamiento.
Ahora que lo pienso, en realidad necesitas BigInteger para poder representar el mismo número de dígitos significativos que NUMBER por defecto a. Nunca he visto a nadie hacer eso y supongo que es una necesidad muy rara. También BigInteger todavía no lo cortaría desde NUMBER puede ser de infinito positivo y negativo.
