SQL Server Decimal (9, 0) vs INT
Un de nos clients utilise pour certaines colonnes le type de données DECIMAL(18,0) dans sa base de données SQL Server 2008R2. Parce que les colonnes croissent assez lentement, il a récemment proposé de changer le type de données en DECIMAL(5,0) pour regagner du stockage.
Selon le bibliothèque MSDN , l'espace de stockage du type de données DECIMAL(5,0) est, tout comme le type de données DECIMAL(9,0), 5 octets. INT est 1 octet plus petit, mais peut tout stocker dans la plage de -2 ^ 31 à 2 ^ 31 au lieu de -99,999 à 99,999 que DECIMAL(5,0) peut stocker. Même le plus grand DECIMAL qui tient sur 5 octets (DECIMAL(9,0)) ne peut stocker que des entiers compris entre -999 999 999 et 999 999 999 (ce qui représente moins de la moitié de la plage INT propose en 4 octets).
Je peux penser à deux "avantages" de l'utilisation de DECIMAL par rapport à INT:
- La possibilité d'ajouter de l'échelle par la suite, sans utiliser plus d'espace de stockage
- La possibilité de mettre à l'échelle la précision jusqu'à 38 chiffres, sans modifier le type de données
mais ce ne sont pas de vrais avantages à mon avis:
- L'ajout d'échelle à des entiers n'a de sens que dans très peu de cas (dans la plupart des cas où l'échelle fait une différence, elle pourrait également être ajoutée au préalable)
- SQL Server voit chaque combinaison précision/échelle comme un type de données différent, donc le type de données n'est pas laissé seul lors de l'augmentation de la précision ou de l'échelle.
Cela me fait me demander: quel est l'avantage supplémentaire d'un type de données DECIMAL(5,0) pour les entiers?
Je suis d'accord qu'il n'y a pas de réels avantages en termes de stockage espace tant que vous comparez DECIMAL (9, 0) vs INT ou DECIMAL (18, 0) vs BIGINT. (Dans un seul octet.)
En termes de traitement, comme @Andriy le dit, le DECIMAL se divisera naturellement en un type qui ne perdra pas la partie fractionnaire, si cela est important pour vous.
D'un autre côté, travailler avec des types INT natifs est beaucoup plus rapide d'un point de vue numérique si vous faites beaucoup de SUM () s ou des comparaisons (telles que la recherche sur les valeurs) car elles sont pipelinées plus efficacement par le CPU. Une comparaison int est deux opcodes d'assemblage (MOV, CMP) mais toute comparaison décimale sera beaucoup, beaucoup plus.
Il semble qu'il y ait il n'y aura aucun avantage en termes d'espace de stockage.
Si votre client craint que vos valeurs soient supérieures à 2 ^ 32-1 (l'entier de valeur positive maximale peut stocker), vous devriez envisager de passer à BigInt - avec 64 bits (8 octets).