L'utilisation de NULL dans les bases de données

[Maz]

Finalement j'ai créé tout un débat...

Personnellement jusque là je suis comme oxman, j'ai toujours utiliser is not null si ma valeur ne doit en aucun cas être null.

Maintenant j'attends le policop d'Argorate s'il arrives à remettre la main dessus ,)

[Argorate]

Je ne dis pas que cela ne fonctionne pas ou que c'est pas faisable, je dis juste pourquoi ne pas éviter de potentiels ennuis quand on peut se l'éviter?
Surtout que le gain des null n'est pas vraiment flagrant pour moi...

Bref, cadeau :








Conclusion, je n'utilise pas les null ^^

[Roworll]

Il y a pourtant des cas ou le NULL signifie quelque chose.
Imaginons une table contenant la liste des Employés.
Pour des raisons administratives, il faut stocker la date d'arrivée et la date de départ. Tu mets quoi dans le champ Date de Départ à la création de l'enregistrement ?
Tu préfèrerais peut être rajouter une table pour stocker exclusivement cette information ?

Ferais-tu de même pour toute information inconnue comme pour le champ NumEmprunteur de la table Livre dans ton exemple ?
Autre question, les étudiants dont l'age n'est pas connu tu stockes quoi, 0, 99 ?
Et si on te demande justement de faire des moyennes sur l'age des étudiants, comment vas-tu exclure les valeurs inconnues ?

Le NULL te seras bien utile dans ce genre de cas.
Dans un monde parfait, tout le monde renseignerait correctement les champs de saisie. Mais c'est loin d'être le cas dans la réalité. Ne pas utiliser NULL c'est alors t'amener à créer d'autres règles tout aussi alambiquées pour gérer le cas de valeur non renseignées.

[niahoo]

Dans un monde parfait on ne mettrait pas ces champs de saisie si on voit que le système tourne quand même sans ces infos.
Après, à chacun sa vision de la perfection :p

[Argorate]

Salut Roworll, je comprends que tu puisses te servir des null, je ne cherche pas a critiquer ou dire que j'ai forcement raison, mais je vais tenter de te répondre:

Il y a pourtant des cas ou le NULL signifie quelque chose.
Imaginons une table contenant la liste des Employés.
Pour des raisons administratives, il faut stocker la date d'arrivée et la date de départ. Tu mets quoi dans le champ Date de Départ à la création de l'enregistrement ?
Tu préfèrerais peut être rajouter une table pour stocker exclusivement cette information ?

J'utilise souvent des timestamp et parfois des dates, enfin peu importe le format, dans un tel cas tu mets 0 (ou 0000-00-00).

Ferais-tu de même pour toute information inconnue comme pour le champ NumEmprunteur de la table Livre dans ton exemple ?
Autre question, les étudiants dont l'age n'est pas connu tu stockes quoi, 0, 99 ?
Et si on te demande justement de faire des moyennes sur l'age des étudiants, comment vas-tu exclure les valeurs inconnues ?

Le NULL te seras bien utile dans ce genre de cas.
Dans un monde parfait, tout le monde renseignerait correctement les champs de saisie. Mais c'est loin d'être le cas dans la réalité. Ne pas utiliser NULL c'est alors t'amener à créer d'autres règles tout aussi alambiquées pour gérer le cas de valeur non renseignées.

Justement, je pense que tous ces cas là peuvent être résolu via une convention. Une convention peu remplacer n'importe quel NULL dans l'absolue.

Concrètement, pour un age non renseigné, tu mets "-1" et ainsi tu l'exclue facilement de toute requête.

Après je ne connais pas tout les cas, il y a peut être des fois où tu n'as pas d'autres solutions, mais j'en ai pas eut l'utilité jusqu'ici.

[Sephi-Chan]

Salut Roworll, je comprends que tu puisses te servir des null, je ne cherche pas a critiquer ou dire que j'ai forcement raison, mais je vais tenter de te répondre:

Il y a pourtant des cas ou le NULL signifie quelque chose.
Imaginons une table contenant la liste des Employés.
Pour des raisons administratives, il faut stocker la date d'arrivée et la date de départ. Tu mets quoi dans le champ Date de Départ à la création de l'enregistrement ?
Tu préfèrerais peut être rajouter une table pour stocker exclusivement cette information ?

J'utilise souvent des timestamp et parfois des dates, enfin peu importe le format, dans un tel cas tu mets 0 (ou 0000-00-00).

Ferais-tu de même pour toute information inconnue comme pour le champ NumEmprunteur de la table Livre dans ton exemple ?
Autre question, les étudiants dont l'age n'est pas connu tu stockes quoi, 0, 99 ?
Et si on te demande justement de faire des moyennes sur l'age des étudiants, comment vas-tu exclure les valeurs inconnues ?

Le NULL te seras bien utile dans ce genre de cas.
Dans un monde parfait, tout le monde renseignerait correctement les champs de saisie. Mais c'est loin d'être le cas dans la réalité. Ne pas utiliser NULL c'est alors t'amener à créer d'autres règles tout aussi alambiquées pour gérer le cas de valeur non renseignées.

Justement, je pense que tous ces cas là peuvent être résolu via une convention. Une convention peu remplacer n'importe quel NULL dans l'absolue.

Concrètement, pour un age non renseigné, tu mets "-1" et ainsi tu l'exclue facilement de toute requête.

Après je ne connais pas tout les cas, il y a peut être des fois où tu n'as pas d'autres solutions, mais j'en ai pas eut l'utilité jusqu'ici.

Je vois absolument pas l'intérêt de mettre en place des conventions plutôt qu'utiliser la bonne valeur, en l'occurrence NULL. Autant s'en servir quand c'est approprié et les gérer comme il faut.

Si tu gères ton cas avec le -1, tu es obligé de modifier ta requête. Donc autant utiliser la valeur NULL qui a du sens, contrairement à une idiote qui corrompt des données avec des informations erronées.

SELECT AVG(age) FROM users WHERE age != -1;

SELECT AVG(age) FROM users;

Autant apprendre à utiliser NULL, ça évite de faire des choses qui n'ont pas de sens.

En mettant en place une convention inutile, tu compliques inutilement le code : il faut mettre le -1 par défaut ou la date 0000-00-00 00:00, puis traiter ce cas à l'affichage, etc.


C'est tellement amateur !

[Roworll]

Le problème est qu'en faisant ainsi tu créés des exceptions que tu dois gérer de manière particulière et qui sont naturellement résolues par l'emploi du NULL.

Pour reprendre tes exemples, en fonction des moteurs de bases de données, affecter 0 dans une date ne stockera pas les mêmes valeurs.
DB2, par exemple, le supporte ('0000-00-00') alors que SQL Server remplace par '1900-01-01'.
Au final, pour analyser tes données par la suite, en fonction du moteur, tu es donc obligé de t'adapter. Garder un NULL éviterait ce problème.

Stocker du -1 dans une colonne de type Age est plutôt malvenu car tu perds la possibilité de n'y mettre que des valeurs non signées. A la limite, tu peux mettre 0 mais ça ne règle pas l'autre partie du problème : tu dois te rappeler d'exclure ces valeurs pour travailler avec la colonne associée.
Donc, lors des requêtes, en transformant le test sur la valeur NULL par un test sur -1, tu remplaces l'exception naturelle "NULL" par une règle applicative liée au "-1".

A supposer que tu recherches tous les élèves mineurs, "age < 18 " suffira amplement si tu utilises les NULL. Dans l'autre cas, tu dois rajouter " AND age <> -1" et si tu oublies ce petit morceau, ta liste sera fausse.

Maintenant, chacun fait comme il l'entend mais d'expérience, dans l'énorme majorité des bases de données mes collègues Oracle / DB2 et moi même gérons, le NULL existe et a son utilité.

Edit :
Oups, cross post avec Sephi-Chan

Re-edit :
SELECT SUM(age) FROM users;
Suffira amplement car les valeur NULL seront naturellement exclues

[Sephi-Chan]

Effectivement, en mangeant je me suis rendu compte que le SUM n'était pas l'exemple le plus intelligent. Et même AVG ignore naturellement les valeurs NULL.

[atra27]

Les NULL, quoi qu'on en pense, on quand même leur utilité.

Ne pas les utiliser est une bétise, mais mal les utiliser en est une aussi!

Dans certains cas on peut utiliser la valeur NULL pour calculer un résultat et retourner un booléen suivant si l'enregistrement existe ou pas (IFNULL ... AS entry_exist)

C'est utile dans le cas des batiments construits ou non...

NULL signifie pas de valeur, si on l'utilise comme tel et UNIQUEMENT comme tel, alors vous n'aurez pas de probléme...
Commele dis sephi, les fonctions du SGBD ignorent le NULL (dans la pluspart des cas) car il est assimilé a aucune valeur bien que l'enregistrement existe! (voir avec count )