Discussion :

[Kropernic]

Bonjour,

Lors de mon dernier séjour* parmi vous (pour le projet de gestion de gifts), j'avais fait connaissance avec la "sulfateuse anti NULL" (dixit CinePhil) de fsmrel.

Ce qui a conduit au final une DB sans aucune colonne autorisant de valeurs nulle et c'est vrai que c'est pas mal pratique jusqu'ici pour le développement de l'applicatif qui s'appuie sur cette DB.

Par contre je m'interroge. Dans ce cas, pourquoi la norme SQL prévoit-elle le marqueur NULL ?


*
je passe régulièrement lire quelques messages mais je préfère m'abstenir de donner de mauvais conseils.

[CinePhil]

Je ne sais pas si c'est la réponse mais le marqueur NULL sert aussi de réponse du SGBD lors d'une requête avec une jointure externe lorsqu'il n'y a ps de ligne dans la table externe satisfaisant la condition de jointure. Il fallait donc bien qu'il figurât dans la norme SQL.

[Kropernic]

Ah oui, effectivement, dans ce cas, c'est bien utile.

En ce qui me concerne, j'étais resté bloqué sur la possibilité d'indiquer qu'une colonne accepte le marqueur ligne comme "valeur" lors de la création d'une table.

Puisque, si la DB est correctement normalisée, les bonhommes NULL disparaissent (si j'ai bien tout compris), je n'en vois pas l'intérêt.

Mais votre exemple répond à la question telle que je l'avais posée.

En fait, je me rends compte que je ne suis probablement pas sur le bon forum pour poser cette question.

[SQLpro]

Comme le dit CinePhil, je résumerais par "chasser le NULL il revient au galop..." par la fait de la jointure externe !
Dès lors la théorie de l'algèbre relationnelle est violée par le fait de cette apparition du NULL (en principe l’algèbre relationnelle manipule des relations à l'aide d'opérateurs qui donnent en sortie de nouvelles relations, donc avec clef, sans doublons et sans null....)

Et puis il fallait bien permettre de reprendre les données pourries des fichiers Cobol ! On l'on avait pris l'habitude de mettre des date à blanc ou des date à 0000-00-00 ou 9999-99-99....

En tout état de cause le NULL doit rester l'exception...

A +

[Kropernic]

Merci pour ce complément de réponse.

Je pense que la question est close

[fsmrel]

En ce qui concerne la jointure externe, n'oubliez pas que — dans le cas de SQL — COALESCE est utile pour empêcher le bonhomme Null de se manifester...

[pachot]

Bonjour,

Entre la théorie relationelle, et son implémentation dans les différents SGBDR il y a un gap. Il y a des points de la théorie qui ne sont pas implémentables de manière performante et scalable - en tout cas sur les technologies actuelles. Et le SQL c'est une norme pour uniformiser certains points d'implémentation. La plupart des editeurs de SGBDR on eu besoin d'implémenter NULL pour permettre des modèles physiques performants, et ils ont donc uniformisé cela dans la norme SQL.

Ce qui a conduit au final une DB sans aucune colonne autorisant de valeurs nulle et c'est vrai que c'est pas mal pratique jusqu'ici pour le développement de l'applicatif qui s'appuie sur cette DB.

Le NULL permet d'enregistrer l'information 'valeur inexistante' dans la même ligne de la même table que les autres informations. Et donc - au niveau physique - de lire cette information sans i/o supplémentaire, de la mettre à jour sans verrou supplémentaire, et en plus de la stocker dans un espace minime (1 octet au maximum, parfois 0 suivant l'implémentation).

Eliminer les colonnes NULLABLE oblige à mettre cette colonne dans une autre table. Y accéder va multiplier la conso i/o, CPU et les verrous. Et suivant qu'on choisisse de stocker l'information 'valeur inexistante' par une ligne dans une table (1), ou par l'absence de ligne (1) on va soit:
(1) devoir stocker une clé primaire en plus pour chaque valeur inexistante
(2) devoir vérouiller toute la table en repetable reads.


Donc à réfléchir en fonction du SGBD et surtout en fonction de la criticité de la performance des accès à cette information (et sa scalabilité). Le SQL et les SGBDR offrent une possibilité d'avoir un modèle physique très performant en utilisant NULL a bon escient. Et où se l'interdire poserait de gros problèmes: de coût si on doit faire 3x plus d'i/o et utiliser 10x plus de CPU, et/ou de scalabilité si on doit vérouiller toute une table au lieu d'un enregistrement.

Cordialement,
Franck.

[Kropernic]

Euh... ok.

Sorry pour l'apparente ingratitude de ma réponse mais vos propos dépasse mon niveau d'expertise actuel...

Je suis donc dans l'incapacité d'en apprécié la juste valeur pour le moment.

Néanmoins, merci pour ce complément d'information.

[pachot]

Sorry pour l'apparente ingratitude de ma réponse mais vos propos dépasse mon niveau d'expertise actuel...

Ah. Désolé
C'était juste pour dire qu'il y a de bonne raison pour avoir droit au NULL en SQL. Et qu'il me paraît dangereux de s'imposer ce genre de règles extrèmes (aucune colonne nullable) pour des raisons théoriques, sans avoir une bonne idée des conséquences lors de l'implémentation physique...

Cordialement,
Franck.

[Richard_35]

Bonjour à tous,

il me paraît dangereux de s'imposer ce genre de règles extrêmes (aucune colonne nullable)

==> tu as, en partie, raison (les extrêmes sont souvent mauvaises conseillères...). En effet, il est dommage, par exemple, de créer des tables pour gérer des données de type "Observations".

En revanche, je pense qu'une colonne "clé étrangère", si elle peut être NULL, devrait toujours être externalisée (quand c'est possible sur le terrain). Pour ma part, la limite se situe à ce niveau.