Eu vi decimal usado em vez de int/long em vários exemplos. Eu só estou tentando entender por que
Provavelmente porque .NET
decimal e Oracle NUMBER mapeia um pouco melhor que long e NUMBER e também lhe dá mais flexibilidade. Se você posteriormente adicionar uma escala na coluna Oracle, você não precisaria alterar o tipo de dados se já usasse decimal . decimal é certamente mais lento que int e long já que os dois últimos são suportados em hardware. Dito isso, você precisa processar uma quantidade séria de dados para que faça alguma diferença. Eu ainda acho que você deveria usar long se é com isso que você está lidando e então você também deve deixar as definições de coluna da tabela representarem isso. NUMBER(18,0) por long e assim por diante. O motivo
decimal mapeia um pouco melhor é que long é de 64 bits e decimal é (mais ou menos) 128 bits. .NET
Tipo:decimal
Intervalo aproximado:±1,0 × 10^−28 a ±7,9 × 10^28
Precisão:28-29 dígitos significativos
Tipo:longo
Intervalo:-9.223.372.036.854.775.808 a 9.223.372.036.854.775.807
Precisão:18 (19 para ulong) dígitos significativos
Oráculo
NUMBER padrão para 38 dígitos significativos e escala 0 (inteiro).
Tipo:NUMBER
Intervalo:+- 1 x 10^-130 a 9,99...9 x 10^125
Precisão:38 dígitos significativos
A Microsoft está ciente do problema e observa
Esse tipo de dados é um alias para o tipo de dados NUMBER(38) e foi projetado para que o OracleDataReader retorne um System.Decimal ou OracleNumber em vez de um valor inteiro. O uso do tipo de dados .NETFramework pode causar um estouro.
Pensando bem, você realmente precisa de
BigInteger ser capaz de representar o mesmo número de dígitos significativos que NUMBER padrão para. Nunca vi ninguém fazer isso e acho que é uma necessidade muito rara. Também BigInteger ainda não cortaria desde NUMBER pode ser de infinito positivo e negativo. 
