Bonjour,
je travaille actuellement pour des sorties de rapports, dans l'optique d'optimiser une base pour effectuer des select rapide, est-il bon d'utiliser des type comme number(6) ou autre?
est ce que ce champ prend 2 exp(20)bits en mémoire ou est ce que oracle lui attribue 2exp(32)bits pour plus de rapidité lors de transfert mais n'autorisera juste pas de valeur décimale plus grande que 6 chiffres?
dans le 1er cas, si il y a une comparaison sur ce champ, n'y aura t'il pas plus de manipulation que si le type etait un entier sur 32 bits par exemple?
 
1) copier la valeur en mémoire
2) dissocier ce qui fait partie du champ
3) effectuer la comparaison
 
merci de votre aide

Euh... C'est pas "2exp(20) bits" ni "2 exp(32) bits" qui sont utilisées hein !
 
Mais simplement 20 bits et 32 bits.
 
Dans le cas du "20 bits", je sais pas où tu a vu ce chiffre. Moi, dans la doc de SQL Server (ça marche pareil qu'Oracle de ce point de vue), lorsque je regarde "numeric", j'ai ça :
 
[citation]
decimal et numeric
Types de données numériques ayant une précision et une échelle fixes.
 
decimal[(p[, s])] et numeric[(p[, s])]
 
Valeurs de précision et d'échelle fixes. Si la précision maximale est utilisée, les valeurs doivent se situer entre - 10^38 +1 et 10^38 - 1. Les synonymes SQL-92 de decimal sont dec et dec(p, s).
 
p (précision)
 
Spécifie le nombre maximal de chiffres décimaux qui peuvent être mis à gauche et à droite de la virgule décimale. La précision doit être une valeur comprise entre 1 et la précision maximale. La valeur de précision maximale est 38.
 
s (échelle)
 
Spécifie le nombre maximal de chiffres décimaux pouvant figurer à droite de la virgule décimale. L'échelle doit être une valeur comprise entre 0 et p. Elle est par défaut 0 et par conséquent, 0 <= s <= p. La taille maximale de stockage varie en fonction de la précision.
 
Précision Taille de stockage (octets)  
1 - 9 5  
10-19 9  
20-28 13  
29-38 17  
[/citation]
 
Donc pour un "number(6)" (ou "number(6,0)" si on écrit correctement) tu auras une représentation sur 5 octets, c'est à dire 40 bits.
 
Un integer sera donc plus petit (et dans tous les cas, un 32 bits est ce qu'il y a de plus rapide à manipuler pour un processeur, sauf les nouveaux processeurs 64 bits, ou on préfèrera le type bigint). Deplus, il est explicité en toutes lettres dans la doc que le type numeric N'est PAS du tout performant pour les calculs. C'est très bien pour faire des clés car les comparaisons (>, =, < ) ne seront pas impactées (ou presque) par la taille de la donnée. Mais pas pour stocker des données, car les calculs (+, -, *, /, ^, etc.) seront extrêment lents.
Dans tous les cas, si c'est pour une donnée à filtrer, c'est pas en jouant sur le type que tu gagneras quoique ce soit. Les INDEX, c'est fait pour ça ! Y'a que les types text, ntext et images qui posent problème pour les filtres; Tout le reste, à partir du moment où il y a un index dessus, est extrêment rapide à retrouver, et ça ne vient même pas du type de données, mais simplement de la structure de l'objet index.
 
PS: et la taille de stockage/représentation en mémoire n'est pas censé impacter quoique ce soit : le serveur de base de données est censé être correctement dimensionné pour supporter les infos qu'il a à traîter, et pas l'inverse !