Valeurs max des données numériques en SQL

Les systèmes de gestions de bases de données (SGBD) ont des limites bien définies pour chaque type de données. Il convient de connaître les valeurs minimums et maximums pour établir correctement le type de chaque colonne. Une colonne qui possède le bon type vis-à-vis des données qu’elle contient aura de bonnes performances et évitera les bugs où les données dépassent la limite établie. Cet article présente les limites des types entiers en SQL.

Types numériques pour MySQL, PostgreSQL, SQL Server …

Les données de types numériques peuvent en général être enregistré dans un colonne de type tinyint, smallint, int ou bigint. Cependant, il faut se fier à la documentation de chaque systèmes pour savoir précisément les types existants. Le tableau ci-dessous présente les types existants dans chacun des plus grands systèmes existants:

A savoir : Oracle stocke les données de type numérique uniquement sous un seul type appelé NUMERIC dont la valeur maximum est de 10¹²⁵.

Valeurs limites des données numériques

Chacun des types de données présentés plus tôt est limité. Pour presque tous les systèmes les données numériques peuvent être négative (colonne signée), mais pour MySQL il est possible de stocker uniquement des valeurs numériques positives (colonne non-signée) ce qui augmente la limite maximum.

A noter (SQL Server) : le tinyint de SQL Server est non-signé (unsigned) ce qui fait que les valeurs vont de 0 à 255.

A noter (PostgreSQL) : les types INT2, INT4 et INT8 sont spécifiques à PostgreSQL. N’essayez pas de les chercher sur un autre systèmes de gestion de base de données.

Bien sélectionner le bon type

En fonction des données à stocker il est important de bien choisir le type d’une colonne. Les données stockées seront les mêmes mais l’espace sur le disque sera différent. Pour faire une analogie, c’est comme s’il faut stocker une boite d’allumette soit dans un tiroir ou soit dans un entrepôt. Tout un entrepôt pour stocker uniquement une boite d’allumette, c’est un peu trop. Toutefois, s’il faut stocker plusieurs milliers de boites d’allumettes, un simple tiroir ne va pas suffire et l’entrepôt est plus approprié.

Choisir le bon type de données permet d’améliorer un petit peu les performances. Mais il faut faire attention, car une application qui sous-estime les données à stockée aura un bug s’il faut enregistrer plus d’information que prévu.

Le premier exemple concret est celui d’un blog peut avoir un bug si les commentaires sont stockés sont stockés sur une table qui utilisent un ID de type smallint et qu’il y a plus de 32.767 commentaires dans la table.

Prenons un exemple pour illustrer ces propos. Imaginons un blog qui utilise MySQL et qui possède une table qui contient les commentaires postés par les internautes. Un champ de cette table stocke les ID qui s’incrémentent à chaque nouveau commentaire. Cela ne sert à rien de choisir un type signé puisque l’ID sera toujours supérieur à zéro.

Par ailleurs, imaginons que l’ID soit stocké sur un smallint unsigned (0 à 65.536). Si le blog à beaucoup de succès, il y aura un bug le jour où la limite de 65.536 commentaires sera atteinte. Pour un petit blog amateur ça suffit largement, mais pour un site qui a d’énorme ambition et qui potentiellement se fait beaucoup spammé, ce chiffre peut être atteins plus rapidement que prévu.