Hello,
j'ai un exposé à faire sur les valeurs NULL, et je dois démontrer que cela pose des pbs. Alors je cherche un exemple où je pourrais démontrer que le résultat d'une requete est complètement faussé à cause des valeurs NULL (exple aboutir au resultat 2 != 2).
Peu importe la conception de la table, on pe volontairement mettre des champs a NULL autorisé meme si cela parait "stupide" de faire ca.
Merci d'avance

un mars et 5? ?

t tjs aussi marrant toi... la prochaine fois evite de perdre 5 sec pr ce genre de reply.
 
C un forum d'aide nan ? (pas la peine de repondre)

Ca me parait difficile. Dès qu'il y a un NULL dans l'opération, ca donne généralement un NULL en résultat

oui c vrai NULL + qqu chose = NULL et tte comparaison ac NULL = fausse.
 
Mais il faut trouve une utilisation judicieuse des null par arrivé à un tel résultat. ALors soit qqun a deja un exple, ou alors c klr ca risk d'etre dur.
Jpense kil faut des req avec group by...
 
OU si qqun a une piste ? une doc la dessus ou autre chose, ca m'interessse.

Je suis bien tombé sur un cas qui peut poser problème, mais c'est au niveau du traitement par PHP
 
Si, avec le LEFT JOIN peut être  
 
2 tables :
   - t1 : a1, b1
   - t2 : a2, b2
si b2 peut être NULL et que tu fais :
SELECT t1.*, t2.b2 FROM t1 LEFT JOIN t2 WHERE a1=a2
Si tu récupères une ligne avec b2 à NULL, tu sais pas si ca vient d'une ligne vérifiant a1=a2 avec b2 à NULL, ou l'abscence de lignes vérifiant a1=a2

oups g reply trop vite... javais pas vu l'exple

c pas possible ke t un null ds b2, a1=a2 ne peut etre vérifié si ya un null. Un null comparé a qque chose est tjs faux. Ou bien est ce php ki est bizarre...

a2 n'est pas NULL. Donc la comparaison a1=a2 peut se faire. Mais comme on récupère pas a2, on sait pas dans quel cas on se situe.
 
 
Pour le PHP, c'est dans la manière de récupérer le résultat. Typiquement, on fait une boucle dans le genre :
while ($tableau = lire_une_ligne($resultat_requete)) {
    // traiter les infos
}
Mais si la requête ne portait que sur une colonne, si celle-ci est à NULL, il sortira de la boucle (comme s'il était arrivé à la fin du résultat de la requête).
 
Bon, c'est pas flagrants comme exemples

au temps pr moi... j'arrive pu a reflechir, il est tard Sur ce jvais me coucher, je reviendrai demain. Merci pr ton aide mrbebert, mais en effet ton pb est du a php, enfin ca doit etre le m pb en jsp,asp...

L'exemple avec PHP, c'est surtout du à la récupération du résultat. Mais pour la requête, ca doit le faire avec tous les SGBD

euh... j'ai pas trop compris en quoi la valeur NULL en elle même est un problème...
Les seuls problèmes que je vois ici c'est soit l'utilisateur qui attaque directement la DB comme un con sans en connaitre la structure, soit une appli mal codée qui accepte de faire des requète absurdes.

 
+1

NULL n'est pas vraiment un problème, c'est comme faire une jointure sur une clè primaire qui n'existe plus --> la jointure ne se fait pas, mais pas d'erreur

 
 
La valeur NULL en elle même n'est pas un problème, mais elle peut être la source de résultat faux lors de certaines requêtes particulières ds des cas de schéma particulier (sans pr autant pr ka la base soit mal faite). C'est ce que je voudrai mettre en évidence avec un exemple concret.
 
 
edit:mon prof ki me demande de faire a eu un exposé ya 2 ans, et le groupe a reussi a monter un exple où il montrait que 2 etait différent de 2, et ca a cause des valeurs NULL.

je suis preneur. mais faut me montrer comment

 
aide constructive, pas un helpdesk. Et typiquement venir avec un prob : "je dois répondre à cette question, donnez moi une réponse" c'est helpdesk-staÿle.
 
maintenant si des gens sont prêt à te répondre, tant mieux pour toi  

----col1 - col2
lig1    2    NULL
lig2    5     7
 
sum (lig1) + sum(lig2) = ?
sum (col1) + sum(col2) = ?

 
En français ca donne quoi ?

 
heu... on peut pas faire de sum sur une ligne ???
 
Sinon un exple d'erreur ac les valeur null
Id  salaire
1   1000
2   NULL
3   1500
4   1200
5   1400
 
Select avg(salaire) FROM table;
->donne resultat X
 
Select sum(salaire) from table;
->donne resultat Y, Y divisé par 5 est différent de X.
 
Et ca car le SGBG ne compte pas le NULL quand y fé avg().
Il faut utiliser aussi je pense, les choix de gestion des valeur null des SGBD (ds ce cas il ne prend pas en compte les champ null lors d'un avg).

L'exemple que tu donnes ici est typiquement une erreur humaine, pas un problème de NULL. Si ton prof cherche à vous faire dire que si un idiot touche à une DB, il va faire n'importe quoi, je ne vois pas trop l'intérêt de l'exposé.
 
C'est aussi intéressant que de faire un exposé sur le fait que qq'un qui n'a pas eu son permis de conduire a plus chance de faire des infractions au code de la route qu'une personne qui l'a.
 
Es-tu sur que c'est VRAIMENT le sujet de ton exposé? A moins que ce ne soit peut-être vos premier cours et c'est une manière de vous faire découvrir les erreurs par vous-même.

oui c'est ce que je voulais dire, quand tu fais un sum sur une ligne comportant un null ca donne un resultat different que si tu fais un sum sur un colonne qui comporte un null. Un des deux fonctionne normalement (je ne sais plus lequel)

C'est surtout le fait que sum sur une ligne, ca n'existe pas...

Ca voudrait dire que la somme par colonne de la somme par ligne (si si, c'est clair ) serait différente de la somme par ligne de la somme par colonne.
Effectivement, c'est intéressant

oui c'est ca je pense
 
gizmo, je ne me souviens plus si ca existe ou non mais le resultat est different
un null dans une ligne fausse le resulat alors qu'un null dans une colonne est accepté, ... ou inversément

Effectivement. Dans un cas, ca te sort une somme, dans l'autre, une erreur. Le résultat est donc différent

 
L'exposé arrive au dernier cours, et en fait c pas un cours de BD classique, c de la BD multidimensionnel (data warehouse = entrepôt de données).
A vrai dire il s'est pas étalé sur le sujet, il nous a juste parlé qu'un groupe a reussi a démontré ke 2 != 2, et le sujet c'est "les valeurs NULL en SQL". Il faut montrer que cela peut poser des pbs. Si on y refléchi bien, les erreurs seront tjs du a des erreurs humaines mais lors de requetes tres compliqué, il peut s'avérer etre dur de trouver pk.
BOn bref, jvais bidouiller des req ds mon coin, jviendrai poster apres mon exposé si j'oublie pas (6 janvier)
merci a ceux ki ont essayé de m'aider.

Exemple de problème avec NULL :
 
select length(champ), champ from table
 
Si une ligne contient champ = NULL, alors le requête plante.
 
Enfin, sous Oracle en tout cas.
 
Sinon, y'a des tas de raisons pour lesquelles NULL peut fausser un résultat, mais comme l'exemple que tu donnes, c'est généralement dû à une mauvaise utilisation des données et non la faute à NULL.
 
Dans ton exemple, quand tu divises par 5, tu fait comme si NULL = 0, ce qui est rigoureusement faux !
NULL indique "pas de valeur", donc on ne s'en sert ni en tant que valeur ni en tant qu'élément. Donc pour une moyenne, on l'ajoute pas au résultat, et on ne l'intègre pas plus dans la division. Chais pas si je suis clair la
 
PS: NULL est par contre très utile quand on sait l'utiliser. Il permet de faire la différence entre une donnée non renseignée et une donnée renseigée à vide. Notamment pour une note, quand on fait la moyenne, on exclue la note pour laquelle l'élève a été absent, on lui colle pas un 0 d'office. NULL est à ce moment indispensable.
 
Sinon, un petit truc qui me vient...
 
Calcul d'un stock :
 
table avec les champs :
- stock physique (ce qu'il y a de recensé en stock)
- stock en préparation (ce qu'il y a en stock, mais qui est réservé par des commandes en cours)
- stock en réception (ce qui est arrivé dans la journée, mais qui n'a pas été compté dans le stock)
 
Mettons que tu as :
 
STK : 1
PRE : 2
REC : 5
 
Si un client veut commander 4 produits, tu fais le calcul :
 
(STK + REC) - PRE, ça te donne le stock dont tu disposes.
 
1 + 5 - 2 = 4
 
Bingo, le client peut passer sa commande.
 
Maintenant, imagine, y'a pas de mouvement de stock en ce moment :
 
STK 5
PRE 0
REP 0
 
5 + 0 - 0 = 5
 
Il peut toujours commander
 
STK : 5
PRE : NULL
REC : NULL
 
(un polio à mis des NULL au lieu de mettre des 0)
 
5 + NULL - NULL = NULL
 
Le client ne peut pas commander, on ne trouve pas de stock.
 
Ca doit répondre à ta question initiale.

merci MagicBuzz, jme servirais de cette exemple bien sympa pr expliquer que NULL+qque chose = NULL

garde aussi sous le coude le coup de la moyenne, parceque NULL n'est pas à banir, au contraire, il faut savoir l'utiliser correctement, c'est ça qui fait toute la différence.

 
Pas sous DB2 : length(null) = 255  

'tain
 
chais que db2 était merdique en certains points, mais aors là, il rejoint Oracle
 
pour info, Oracle fait pas la différence entre chaîne vide et NULL quand il travail en varchar2
 
Y'a pas à dire, parmis les leaders des SGBD, je vais finir par être convaincu que c'est SQL Server de M$ qui a le moins de "grosses merdes" de ce genre...

PS: vérifie quand même que lenght() sous DB2 c'est la longueur d'une chaîne de caractère et pas la longueur du champ par exemple. Parcequ'à ce moment ça pourrait expliquer la valeur bizarre

 
non c'est bien la longueur de la chaine. Maintenant, il est probable qu'en cas de "chaine = null", ca renvoie la longueur du champs.
 
Mais bon DB2 c'est tellement bien foutu, tellement user-friendly  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
vive SQL Server !

BOn alors mon exposé s'est bien passé (pr ceux ke ca interesse). Le prof avait l'air content. Merci a MagicBuzz, le prof a particulierement bien aimé ton exple très representatif des erreurs que peuvent entrainer les null.
Par contre j'ai oublié de demander le fameux exple 2!=2. SI je le revois (g pu ce cours now) je lui demanderai.
+++

Tant mieu