État actuel de INTEGER par rapport à NUMBER dans Oracle
J'utilise Oracle Database 12c Enterprise Edition version 12.1.0.2.0 - Production 64 bits et j'essaie de décider d'utiliser INTEGER ou NUMBER pour un champ de nombre entier qui contiendra un LONG à partir de Java.
Pour référence:
Long.BYTES = 8
Long.SIZE = 64
Long.MAX_VALUE = 9223372036854775807 / 2^63-1
J'ai été dirigé vers un article de blog relativement ancien à partir d'un réponse sur Stack Overflow qui suggère que vous ne devriez jamais vraiment utiliser INTEGER car il a des performances significatives par rapport à l'utilisation de NUMBER. Même pour seulement [~ # ~] id [~ # ~] colonnes.
INTEGER est toujours plus lent que NUMBER. Puisque l'entier est un nombre avec une contrainte supplémentaire. Il faut des cycles CPU supplémentaires pour appliquer la contrainte. Je n'ai jamais observé de différence, mais il pourrait y avoir une différence lorsque nous chargeons plusieurs millions d'enregistrements dans la colonne INTEGER. Si nous devons nous assurer que l'entrée est des nombres entiers, alors INTEGER est la meilleure option. Sinon, nous pouvons nous en tenir à NUMBER type de données.
Cet article indique également que "INTEGER est équivalent à NUMBER (38,0)" que je connaissais déjà. Ce que je n'ai pas été en mesure de déterminer si elle est équivalente aux éventuels problèmes de performance qui sont soulevés.
- Je veux m'assurer que toutes les valeurs ne sont que des nombres entiers.
- Je travaillerai régulièrement avec des millions de lignes et je rejoindrai cette colonne car ce sera une clé étrangère pour des centaines de tables.
Le documentation Oracle dit que
INTEGER, INT et SMALLINT sont tous mappés vers NUMBER(p,0)
Je prévois donc d'utiliser NUMBER(38,0) comme je l'ai toujours fait, beaucoup de bases de données et de tables héritées dont j'importe des données stockant réellement ces informations ID dans une VARCHAR(50) et la les données sont terriblement horribles à cause des gens qui ajoutent préfixe/suffixe caractères pour indiquer état; comme z343234 signifie désactivé. J'essaie donc de nettoyer ces données dans les nouveaux systèmes et de ne pas permettre les perversions que les développeurs/analystes commerciaux précédents ont faits. Je ne suis pas concerné par la sauvegarde des drapeaux corrompus et d'autres données, juste la partie numérique.
Je travaille avec tellement de moteurs de base de données différents que je ne peux pas suivre les derniers idiomes.
Ces problèmes de performances sont-ils réellement préoccupants 10 ans plus tard?
Le blog
La logique derrière ce poste est si ridicule qu'elle mérite une réponse sarcastique.
Oracle fait le "est-ce un entier?" vérifiez pendant qu'il attend l'appel d'E/S sur le disque pour renvoyer les données dont il a besoin pour valider la contrainte de clé primaire.
Je crois que ces améliorations de performances ont été implémentées dans Oracle version 2.
En réalité, le nombre de cycles d'horloge nécessaires pour effectuer une telle vérification est si insignifiant qu'il est facilement caché dans le bruit des opérations normales de l'ordinateur. Vous ne pourriez probablement pas mesurer la différence de performances même sur un VAX/VMS. (beaucoup plus vieux que "10 ans")
INTEGER vs NUMBER vs PLS_INTEGER
Comme vous l'avez vu, INTEGER est NUMBER(38,0). Il ne devrait pas y avoir de différence de performance mesurable.
Une différence peut apparaître lorsque vous parlez de PLS_INTEGER Vs NUMBER. La plupart des repères que j'ai vus qui prouvent que cela est vrai sont des calculs intensifs. Comme vous ne faites pas d'équations différentielles avec cette valeur, le "gain de performances" ne s'appliquerait pas à votre cas.
Je vous recommande de rester avec INTEGER ou NUMBER(38,0)
Suggestion de modèle de données
Le nombre et le drapeau doivent être dans deux colonnes différentes. N'hésitez pas à utiliser un virtual column (3e colonne) pour récupérer la chaîne d'origine. Je vous recommande d'enregistrer la valeur de la chaîne d'origine dans un champ de type "commentaires/notes" afin que les humains puissent la rechercher au cas où votre logique virtual column Correspondrait à ce que l'humain a réellement tapé.