J'ai vu décimal utilisé à la place de int/long dans divers exemples. J'essaie juste de comprendre pourquoi
C'est probablement parce que .NET decimal et Oracle NUMBER cartes un peu mieux que long et NUMBER et cela vous donne également plus de flexibilité. Si vous ajoutez ultérieurement une échelle dans la colonne Oracle, vous n'auriez pas à changer de type de données si vous avez déjà utilisé decimal .
decimal est certainement plus lent que int et long puisque les deux derniers sont pris en charge dans le matériel. Cela dit, vous devez analyser une quantité importante de données pour que cela fasse une différence. Je pense toujours que vous devriez utiliser long si c'est ce à quoi vous avez affaire, vous devez également laisser les définitions des colonnes du tableau le représenter. NUMBER(18,0) pour long et ainsi de suite.
La raison decimal cartes un peu mieux est que long est 64 bits et decimal est (en quelque sorte) 128 bits.
.NET
Saisissez :décimal
Plage approximative :±1,0 × 10^−28 à ±7,9 × 10^28
Précision :28-29 chiffres significatifsTapez :long
Plage :-9 223 372 036 854 775 808 à 9 223 372 036 854 775 807
Précision :18 (19 pour ulong) chiffres significatifs
Oracle
NUMBER par défaut à 38 chiffres significatifs et échelle 0 (entier).
Tapez :NUMÉRO
Plage :+- 1 x 10^-130 à 9,99...9 x 10^125
Précision :38 chiffres significatifs
Microsoft est conscient du problème et note
Ce type de données est un alias pour le type de données NUMBER(38) et est conçu pour que OracleDataReader renvoie un System.Decimal ou OracleNumber au lieu d'une valeur entière. L'utilisation du type de données .NETFramework peut provoquer un débordement.
À bien y penser, vous avez en fait besoin de BigInteger pouvoir représenter le même nombre de chiffres significatifs quant à ce que NUMBER par défaut. Je n'ai jamais vu personne faire cela et je suppose que c'est un besoin très rare. Aussi BigInteger ne le couperait toujours pas depuis NUMBER peut être d'infini positif et négatif.
