Discussion :

[J@ckHerror]

Ok et merci pour les infos.

Pour être franc je n'ai jamais utilisé coalesce, mais je vais le tester. Il est vrai que ces derniers temps (années ) j'étais plus attentif à .net pour augmenter mon niveau et j'avais un peu délaissé la partie DB. Maintenant que je suis seul pour tout faire, je me rend compte que la partie DB peux aider pas mal, mes premières fonctions et procédures sont toutes récentes par exemple et là vous venez de me donner un nouvel axe de progression, et pour ça

J@ck.

[DotNetMatt]

plutôt que de me faire ch*** avec .NET (d'ailleurs, dans un dataset, dès qu'il y a un NULL, ça gueule rien que lorsqu'on essaie de le remplir), je travaille à la source où ça va très vite puisqu'il suffit d'un coalesce avec toute la brochette de paramètres qu'on aurait envie de lui mettre.

Bien sûr, c'est une convention qui m'est propre et que je fais appliquer où je bosse (en même temps, on est deux et c'est moi le chef pour les DB, ça aide^^). Ca simplifie directement les choses au niveau .NET. On affiche et c'est tout. Si c'est null. Bin on a directement le bon affichage.

C'est bizarre car au final ca n'est pas bien sorcier... Il faut juste se rappeler que null en C# et null en SQL sont 2 choses différentes (sans parler de "" qui est encore autre chose).

Quand tu dis "on a directement le bon affichage", c'est probablement vrai dans la majorité des cas, mais il y a des moments où on pourrait vouloir traiter le null dans le code et là avec ta méthode ca ne fonctionnera pas car on ne pourra différencier entre null et "". Par exemple on peut avoir un truc du genre "si null, alors je récupère tel enregistrement pour afficher telle info".

Enfin, quand tu dis que le dataset gueule quand il y a des null, c'est une bonne raison de plus pour s'en passer ! Le dataset fait partie de la préhistoire de .NET et était surtout utile pour combler l'absence des listes (ou plus généralements des objets qui implémentent IEnumerable et autre). Rien de tel que des listes et si on a pas le temps de se palucher une DAL, Entity Framework (ou tout autre ORM) permet d'automatiser bien des choses sans avoir toute la lourdeur du DataSet...

[Kropernic]

C'est bizarre car au final ca n'est pas bien sorcier... Il faut juste se rappeler que null en C# et null en SQL sont 2 choses différentes (sans parler de "" qui est encore autre chose).

Quand tu dis "on a directement le bon affichage", c'est probablement vrai dans la majorité des cas, mais il y a des moments où on pourrait vouloir traiter le null dans le code et là avec ta méthode ca ne fonctionnera pas car on ne pourra différencier entre null et "". Par exemple on peut avoir un truc du genre "si null, alors je récupère tel enregistrement pour afficher telle info".

Enfin, quand tu dis que le dataset gueule quand il y a des null, c'est une bonne raison de plus pour s'en passer ! Le dataset fait partie de la préhistoire de .NET et était surtout utile pour combler l'absence des listes (ou plus généralements des objets qui implémentent IEnumerable et autre). Rien de tel que des listes et si on a pas le temps de se palucher une DAL, Entity Framework (ou tout autre ORM) permet d'automatiser bien des choses sans avoir toute la lourdeur du DataSet...

Oh mais je n'utilise pas les datasets, bien au contraire. Même si cela me prend un rien plus de temps, j'écris toujours ma DAL moi-même. Comme ça, je suis sûr que les choses sont bien faites et en cas de bug, je n'ai pas à m'interroger si oui ou non il pourrait survenir dans un brique que je n'ai pas construite et sur laquelle je n'ai pas la main.

Sinon, concernent "on a directement le bon affichage", tu as tout à fait raison quand tu dis que, parfois, on ne voudra pas une chaîne vide à la place du NULL. Personnellement, je gère tous les accès DB via des procédures stockées (et les users n'ont accès qu'à ces dernières). Du coup, en cas dans NULL dans une requête, je peux gérer au cas par cas ce que je veux afficher. Mais faut bien dire que j'ai assez rarement des NULL dans mes requêtes.

[sinople]

Hello

Si l'instruction Iif() évalue effectivement les 3 arguments, ce qui la rend peu pratique pour ce genre de cas. L'instruction If() n'évalue que la condition nécessaire.

Il suffit donc d'enlever un i à ton iif() pour que ça fonctionne correctement (faut juste pas s'emmêler les pinceaux avec les deux instructions). Au passage ceci s'avéra aussi fort pratique pour vérifier qu'un objet ne soit pas Nothing avant d'accéder à une de ces propriétés.

Quand à l'utilisation d'un COALESCE dans la requête pour ne pas avoir de NULL, c'est acceptable dans certains cas (typiquement pour du reporting ou autre opération à sens unique). Mais c'est inacceptable pour du traitement de donnée vu qu'une absence de valeur n'est pas égale à un champ vide.

Pour la petite histoire, l'article suivant aurait pu se nommer. Madame Null est devenue une expert mondial d'audit de qualité de programmation sans faire d'étude (j'ose pas imaginer son cousin germain Mr. Drop table).
http://www.20min.ch/ro/multimedia/st...story/25432909

[Kropernic]

Outre le côté cocasse de l'histoire qui m'a fait rire, ça démontre juste que ceux qui ont codés les applications en question ont codé ça avec les pieds.

Car pour moi (mais je suis sûr que pour toi aussi), la chaîne "NULL" est strictement différent du marqueur NULL et ne peuvent pas se confondre.

Je programme des applications de gestion interne pour la boite où je bosse tous les jours et je n'ai jamais utilisé une seule requête qui renvoie un marqueur NULL dans son résultat. Pourtant, tout va très bien (madame la marquise).

De plus, j'ai dit que je ne renvoie jamais de marqueur NULL dans un résultat mais je n'ai jamais dit que je n'en passais pas à mes procédures stockées au besoin.

Bref, attention à ne pas tout mélanger (comme les programmes de l’article).

[sinople]

Sauf que quand tu mets un COALESCE dans ta requête, tu remplaces les NULL par une valeur (-1,0,"","null","n.a", je sais pas quoi).

Quand tu remontes l'enregistrement pour un update, il devient impossible de savoir si la valeur de remplacement doit représenter un NULL ou la valeur de substitution (et c'est bien ce qui a l'air d'arriver dans l'article cité.). Sauf si bien sur tu as un champ supplémentaire boolean (HasValue) stockant cette information d'absence de donnée sur un autre champ (ou que ça soit écrit dans le marbre que cette valeur ne fasse pas partie l'ensemble de travail), mais là on rentre dans un autre débat.

Dans certains cas, il est plus intéressant de ne pas accepter de NULL sur le champ dans la BD et de mettre une valeur par défaut (chaîne vide sur un text), surtout sur les champs valeur (pas les clés étrangères) qui sont optionnels.

Enfin on rencontre la même problématique avec les variable d'objet en référence (le fameux Nothing), la preuve avec Entity Framework ont ne travaille plus avec des DBNull mais des nothing. Donc savoir comment gérer ça correctement (pas avec le Iif()) me semble être essentiel.