Bonne lecture !

Voici donc la démonstration que NULL en SQL n’est pas une valeur …

C’est très simple : exécutez la requête suivante :

Vous pensez que l’on va obtenir OK … Donc vous pensez que NULL est une valeur et c’est faux : on obtiendra KO !
Vous pouvez faire l’expérience avec n’importe quel autre opérateur arithmétique (>, >=, <, <=, <>, !=) : vous obtiendrez toujours KO

Ceci prouve que NULL n’est pas une valeur : en SQL, c’est un marqueur qui signifie l’absence de valeur.
C’est d’ailleurs la raison pour laquelle en SQL, on écrit IS NULL dans un prédicat (WHERE ou JOIN), et non pas = NULL.
En revanche, dans un langage comme Java ou C#, null == null est effectivement vrai.

En effet, beaucoup de langages évaluent les expressions logiques suivant deux valeurs : true ou false.
Mais en SQL, un prédicat et évalué comme étant TRUE, FALSE ou UNKNOWN.

De la même façon, toute autre opération (NULL [operateur_arithmétique] [valeur]), peu importe le type de [valeur], retourne toujours NULL :

– NULL + 4
– NULL + ‘uneChaine’
– REPLACE(uneChaineNULL, ‘qqch’, ‘_qqch’)

Enfin, NULL est traité différemment par les différents opérateurs que l’implémentation SQL Server de SQL propose :

– Les filtres de requête (ON d’une jointure, WHERE (et AND qui suivent) et HAVING) évalueront NULL comme ne vérifiant pas le prédicat
– Une contrainte CHECK évaluera NULL comme vérifiant le prédicat
– Une contrainte UNIQUE prend NULL comme une valeur, ce qui est totalement faux
– Une opération avec les opérateurs d’ensembles UNION, EXCEPT et INTERSECT traite NULL comme une valeur, ce qui est également faux
– GROUP BY groupe tous les NULL dans un groupe distinct
– ORDER BY trie le NULL ensemble
– La fonction COUNT() tient compte de NULL
– Les autres fonctions d’agrégation n’en tiennent pas compte

Attention à NULL

ElSüket

=> Utiliser plusieurs colonnes de type BIT pour représenter un état

Certes cela consomme moins d’espace, mais l’atomicité du sens de la valeur est alors perdue …
Il sera donc avantageux d’utiliser une colonne de type TINYINT qui consomme seulement un octet, en laissant la porte ouverte à de nouveaux états …

=> Utiliser le type TIME pour stocker une durée

SQL Server 2008 a introduit plusieurs nouveaux types de données permettant de stocker des valeurs temporelles, notamment le type TIME, qui comme son nom l’indique, permet de stocker un horaire, et non pas une durée.
Si d’aventure nous devons stocker une durée supérieure à 24h, comment allons-nous alors procéder ? Ce choix reste acceptable si l’on est absolument certain que la durée ne dépassera jamais 24h, mais il est plus simple de stocker une durée comme un entier, ce qui permet d’utiliser très simplement la fonction DATEADD().
Une autre solution est de stocker la date de début et la date de fin de l’opération, et d’ajouter une colonne calculée qui spécifie la fonction DATEDIFF().

=> Utiliser le type DATETIME au lieu du type SMALLDATETIME

Tout aussi regrettable, la confusion entre ces deux types de données :

– DATETIME nécessite 8 octets, et permet de stocker des dates avec une précision à 3ms,
– SMALLDATETIME nécessite 4 octets, et permet de stocker des dates avec un précision à la minute.

Il est donc absurde de stocker des dates au type DATETIME pour une application qui n’en a pas besoin, comme par exemple un centre de documentation qui propose l’emprunt de livres …

Encore une fois cela a un impact important sur l’indexation, puisqu’il faudra plus de pages pour stocker la même donnée, et traverser plus de niveaux intermédiaires … il en résultera donc des lectures de pages supplémentaires et inutiles, pourrissant le cache de données, et ralentissant l’exécution des requêtes …

=> Stocker des chaînes de caractères numériques ou forcément latins dans une colonne de type Unicode (NCHAR, NVARCHAR)

Pourquoi stocker une référence, une adresse mail, un numéro de téléphone, ou un code postal en Unicode ?
Tout simplement pour consommer deux fois plus d’espace !
En effet tout caractère stocké au type de données Unicode occupe 2 octets, contre seulement 1 en CHAR ou VARCHAR.

=> Utiliser le type VARCHAR au lieu de CHAR

Si par exemple nous avons des codes qui contiennent des lettres, mais dont est certain qu’ils seront toujours représentés sur 6 caractères, alors pourquoi stocker ceux-ci dans une colonne de type VARCHAR ?
En effet le type VARCHAR fait consommer 2 octets en sus de tous les caractères de la chaîne, qui permettent de stocker l’offset de fin de cette chaîne.
Ce n’est pas le cas lorsqu’on stocke ce genre de données au type CHAR.

=> Stocker des dates dans une colonne de type CHAR | NCHAR | VARCHAR | NVARCHAR

On se sert d’une colonne de type chaîne pour stocker une date au format désiré, par exemple DDMMYYYY HH:mm:ss …
Mais il y a pire encore : stocker ces dates au format Unicode (NCHAR, NVARCHAR) surtout quand on sait que les dates ne comprennent jamais de caractères Unicode.
Rappelons donc que ces 4 types de données ne doivent servir exclusivement qu’au stockage de chaînes de caractère, et que les types Unicode permettent de stocker des caractères non latins, comme ceux des langues arabes et asiatiques.

Conséquence directe de ce choix : la perte d’intégrité des données, puisque dans une colonne de type chaîne de caractère, on peut stocker une représentation d’une date, mais aussi n’importe quelle autre chaîne de caractères.
Bien sûr, certains me répondront que l’on peut mettre une contrainte de domaine (CHECK) sur la colonne … outre le fait que la comparaison de chaînes est coûteux en ressources système, que ferez-vous en cas d’erreur ?

Autre conséquence : comment interroger la table pour retourner les données qui ont été stockées entre deux dates ? Comment utiliser les fonctions consacrées aux dates comme DATEADD(), DATEDIFF(), … ?

Enfin l’efficacité d’un index sur une colonne de type chaîne de caractère est plus connue pour être faible.

Tout cela pour ne pas avoir utilisé le type DATETIME ou SMALLDATETIME … Il faut avouer que c’est de l’auto-flagellation !

=> Utiliser le type INT au lieu de SMALLINT, TINYINT ou BIT

Voilà un précepte que l’on rencontre aussi souvent qu’il est incohérent.

Au nom de la simplicité (mais laquelle ?), nombreux sont ceux qui souhaitent stocker la valeur de clé primaire de tables de référence (jours de la semaine, quelques états possibles d’une entité (en veille, en chargement, allumé, en cours d’extinction), et j’en passe …) dans une colonne de type INT.

Alors qu’à l’évidence, il n’y aura jamais plus de 256 jours dans une semaine, stockons donc tout cela sur les 4 octets d’une colonne de type INT, au lieu de stocker la même information dans une colonne de type TINYINT, pour seulement 1 octet.
De cette façon on pourra avoir des indexes plus volumineux et moins efficaces lors des jointures, tout en pourrissant le cache de données !

=> Utiliser les types FLOAT ou REAL au lieu de NUMERIC ou DECIMAL

Les types FLOAT et REAL, réservés aux valeurs numériques imprécises, sont appropriés dans le cas où l’on a affaire à une application scientifique qui effectue des calculs en virgule flottante.

=> Utiliser les types MONEY ou SMALLMONEY au lieu de NUMERIC ou DECIMAL

Il s’agit ici plus d’une anomalie que d’autre chose, et je ne m’explique toujours pas la présence des types de données MONEY et SMALLMONEY, alors que NUMERIC et DECIMAL conviennent tout à fait au même usage.
Le pire, c’est que les premiers fonctionnent très bien pour toute opération arithmétique de base, mais entraînent des imprécisions puisqu’ils sont stockés comme des nombres à virgule flottante.
Si on doit donc utiliser des pourcentages sur des valeurs monétaires, ou utiliser des taux de change, on préfèrera les types NUMERIC ou DECIMAL, qui sont précis.

=> Le comble de la médiocrité : le « type » sql_variant

Ce pseudo-type de données est le pire qui ait été inventé : on peut tout y stocker, des chaînes de caractère, des entiers, des décimaux, un document XML, …

Voyons tous les inconvénients de ce « type » :
– Il n’est pas entièrement supporté par ODBC, qui convertit de plus toute valeur automatiquement en NVARCHAR(4000)
– On ne peut bien évidemment pas l’utiliser pour la définition d’une colonne calculée,
– On ne peut pas utiliser l’opérateur LIKE sur une colonne de ce « type »,
– Il ne peut pas être utilisé pour définir une clé primaire ou étrangère
– On ne peut pas utiliser de fonction d’aggrégation
– On ne peut pas effectuer d’opération arithmétique

Finalement tout doit être fait à l’aide des fonctions CAST() ou CONVERT(), ce qui rend bien sûr un prédicat de filtre non SARG-able

Si certains diront que c’est approximativement la même chose, et que s’attacher a ce type de détails revient à chercher des poils sur les œufs, je vais démontrer que faire cet abus de langage montre qu’on est assez imprécis …

=> Une colonne d’une table de base de données n’est pas un champ

La différence la plus directe entre une colonne et un champ est qu’un champ est défini dans un enregistrement à destination d’une application particulière, alors qu’une colonne d’une ligne dans une table est définie en totale indépendance des applications qui liront ou modifieront ceux-ci.

Une autre discordance tout aussi importante est que toute colonne d’une table de base de données stocke des valeurs scalaires et peut surtout être NULLable, notion rarement implémentée dans tout autre langage que SQL.
Et je suis sûr que nombre d’entre nous ont déjà eu des problèmes d’intégration de données à partir de fichiers plats dans une base de données, où il faut modifier le comportement par défaut de l’outil d’intégration pour lui faire remplacer un saut de champ ou une chaîne vide du fichier pour voir son intégration dans la table cible remplacée par NULL.

Un nouvel éloignement peut être simplement mis en évidence si nous modifions l’ordre des champs que nous avons établi pour une application et que nous tentons de le faire lire à une autre application : l’ordre n’a aucune influence sur les tuples de valeurs stockées par les colonnes d’une table, car celles-ci sont directement étiquetées par leur nom, et non pas désignées par leur ordre d’apparition dans le fichier ou le flux.

Un écart plus spécifique est celui de l’impossibilité pour un champ d’être soumis à des contraintes de domaine (CHECK constraints) ou de valeur par défaut (DEFAULT constraints).

Pour en revenir aux problèmes que l’on peut rencontrer lors des intégrations de données contenues dans des fichiers plats à destinations de tables de base de données, il arrive parfois qu’il y ait discordance lors du transtypage d’un champ vers une colonne : cela est tout simplement du au typage fort des colonnes, alors que les champs ne sont pas typés.
Il s’agit alors pour le moteur d »intégration de transtyper automatiquement, par exemple, d’une chaîne de caractère vers un entier …

=> Une ligne d’une table de base de données n’est pas un enregistrement

De la même façon que pour les champs, la structure des enregistrements est déterminée pour l’usage d’une application.
Encore une fois, l’ordre physique des champs de l’enregistrement prime, alors que l’ordre des colonnes d’une ligne n’altère pas la signification du tuple représenté par une ligne de base de données : {A,B,C} en base de données signifie la même chose que {C,A,B}, ce qui n’est pas le cas dans un fichier ou un flux.

Toujours de la même manière que pour les colonnes, une ligne est définie dans un schéma de base de données, et non pas par l’application qui en est la destination.
L’illustration en est la notion d’ensemble vide : alors qu’il est impossible de signifier cette notion dans un fichier, qui restera vide, une table de base de données, même si son cardinal est nul, conserve sa structure fortement typée, ses contraintes, …

Enfin toute ligne d’une table de base de données est lue comme l’unité de travail la plus simple, alors qu’on peut extraire seulement certains champs d’un enregistrement.

=> Une table n’est pas un tableau

Comme nous l’avons vu précédemment, la notion d’ordre en base de données n’existe pas, alors que dans un fichier ou flux, c’est tout à fait vrai.
En effet une table n’est pas accédée de façon séquentielle, et en ce sens l’utilisation de curseurs est un non-sens pour les traitements en base de données, puisqu’on peut associer à un curseur les mots NEXT, PREVIOUS, FIRST et LAST.
Notons au passage que les curseurs sont un héritage de ce bon vieux COBOL, qui permettait en outre de lire des fichier dits séquentiels.

Mais plus important que cela, c’est surtout les contraintes d’intégrité que l’on peut définir entre les tables d’une base de données, et qu’il n’est pas possible de définir dans un fichier, ou entre plusieurs fichiers.

Aussi, un fichier est attaché à sa méthode de stockage sur disque, ce qui n’est pas le cas d’une table de base de données, qui en fait totale abstraction.

Tout cela pour bien comprendre la différence fondamentale qu’il y a entre penser par ensembles, et penser séquentiellement.

ElSuket