dans la base de données j'ai un table Client qui contient le champs nom_prénom ( si le client est un individu ) et le champs raison social ( si le client est une société ) danc il existe dans ma table des enregistrements avec la valeur null , je ne souhaite pas de les afficher dons j'ai essayé avec
1) select * from client where nom_prénom is not null;
2)string a ="";
select * from client where nom_prénom ='"+a+"';
il me dit qu'il existe un erreur dans le syntaxe !!
Salut,
select * from client where nom_prénom is not null; devrait normalement fonctionner ,c'est peut être du a ton champ nom_prénom avec un accent sur le e,je te conseille d'éviter de mettre des accents pour le nom des champs.
dans la base de données j'ai un table Client qui contient le champs nom_prénom ( si le client est un individu ) et le champs raison social ( si le client est une société ) danc il existe dans ma table des enregistrements avec la valeur null , je ne souhaite pas de les afficher dons j'ai essayé avec
Clairement c'est un problème de conception, tu aurais du faire de l'héritage.
Tu peux faire des vues, pour séparer distinguer les sociétés des individus:
CREATE VIEW individu AS
SELECT clientId AS id, nom_prenom
FROM client
WHERE raison_social IS NULL;
-- et
CREATE VIEW societe AS
SELECT clientId AS id, raison_social
FROM client
WHERE raison_social IS NOT NULL;
Pour récupérer les infos de societe uniquement:
SELECT *
FROM societe;
Si ça ne va pas, montre nous la structure des tables.. (cf. ma signature).
@DarkMort : null n'est jamais égal à quoi que ce soit. C'est un peu sa raison d'être d'ailleurs.
Tu peux tracer NULL=NULL, tu obtiendras false... contre toute logique
NULL est une des pires horreurs de SQL. Nous serions bien plus heureux si NULL n'existait pas.
NULL n'a essentiellement aucune sémantique correcte, est utilisé en de nombreux endroits du langage SQL de façon incohérente. Il pose de nombreux problèmes quand on veut traiter des données issues d'une requête SQL dans un autre langage de programmation.
Il faut absolument mettre tous les champs en "NON NULL" par défaut. Si le langage des types de SQL n'était pas si pauvre (pas de type somme/union), on pourrait même s'en débarasser complètement en définissant un type explicite pour les champs pouvant ne pas avoir de valeur, comme les option/Maybe des langages ML.
Je suis désolé @bluestorm, mais le NULL est très important.
L'intérêt principal est de marquer l'absence de valeur.
Exemple:
Prenons le cas d'une table personne avec les champs {nom, prénoms, date_de_naissance, fax} avec tous les champs à NOT NULL (comme vous le préconisez)
comment ferait-on pour remplir le champ date_de_naissance si la date de naissance n'est pas connue ; ce champ devant être obligatoirement renseigné d'après la clause NOT NULL ?
La plupart du temps on voit des développeurs y mettre 1/1/1900 ou autre date bizarre (00/00/0000) (suivant les "SGBD" qui le permettent), alors qu'un simple NULL aurait réglé le problème.
Cependant je suis tout à fait d'accord sur sa mauvaise utilisation chez certains développeurs. En fait, ceux ci le considèrent comme une valeur alors que c'est un marqueur (comme le marqueur de fin de pointeur).
per_id nom prenom
1 DURANT Paul
2 DUPONT Jean
3 KOSARZY Pierre
per_id dateNaiss
2 1983-01-01
Tu peux en faire une vue pour tout récupérer simplement:
CREATE VIEW vue_personne AS
SELECT per_id, nom, prenom, COALESCE(dateNaiss, 'inconnu') AS dateNaiss
FROM personne
NATURAL LEFT JOIN dateNaiss
per_id nom prenom dateNaiss
1 DURANT Paul inconnu
2 DUPONT Jean 1983-01-01
3 KOSARZY Pierre inconnu
Les âmes sensibles diront que ça fait "beaucoup de table", il y a "beaucoup de jointures" donc c'est compliqué et pas performant.
Ça ne tient pas debout.
Soit l'on travail sans NULL, soit on fait avec, et bonne chance.
Rappel: dans la Théorie Relationnelle, de laquelle s'inspire le SQL et donc toute l'industrie des SGBD actuels, NULL n'existe pas, ça n'a aucun sens.
La dernière réponse n'a pas vraiment de sens... Un date de naissance n'est pas une chaine de caractères, mais bien de type DATE, donc mettre 'inconnu' n'est pas vraiment pertinent puisque ça implique de ne plus travailler sur une date, mais sur une chaine de caractères.
Le but des types est d'avoir un certain formalisme à respecter.
Si la base est amenée à passer entre différentes mains, au bout de quelques temps, tu risques de finir avec un truc du style :
2000-01-01
01-01-2000
01/01/2001
...
En mettant le champ avec un type DATE (et non VARCHAR), ce risque est moindre...
Quitte à mettre une valeur repère pour les champs inconnus, lorsqu'il s'agit d'une date, je préfère utiliser la valeur 0000-00-00...
Si la base est amenée à passer entre différentes mains, au bout de quelques temps, tu risques de finir avec un truc du style :
2000-01-01
01-01-2000
01/01/2001
...
Pas du tout.
Tu te réfère à la vue là..
Mais dans la table, où est réellement stockée la date (dateNaissance) y a aucun soucis....
Citation : Wapiti89
Quitte à mettre une valeur repère pour les champs inconnus, lorsqu'il s'agit d'une date, je préfère utiliser la valeur 0000-00-00...
Ça c'est d'un ridicule.
D'autant plus que la date 0000-00-00 n'existe pas, elle ne devrait même pas faire parti de l'ensemble des valeur possible du type DATE, encore une connerie de MySQL.
cela deviendra vite compliqué avec une petite vingtaine de tables.
2- tu utilises "coalesce" dans ta vue pour contourner le NULL utilisé par LE SGBD pour marquer son absence de valeur (tiens tiens) dans un résultat donné. (Cela semble bizarre d'utiliser cela pour éviter les NULL).
3- le fondateur de la théorie relationnelle (Dr CODD) a établit 12 règles pour définir ce qui est exigé d'un système de gestion de base de données (SGBD)
Règle 3 : Traitement des valeurs nulles :
Le système de gestion de bases de données doit permettre à chaque champ de demeurer nul (ou vide). Spécifiquement, il doit soutenir une représentation "d'information manquante et d'information inapplicable" qui est systématique, distincte de toutes les valeurs régulières (par exemple, "distincte de zéro ou tous autres nombres," dans le cas des valeurs numériques), et ce indépendamment du type de données. Cela implique également que de telles représentations doivent être gérées par le système de gestion de bases de données d'une manière systématique.
sur ce point rien à commenter il a tout dit.
Citation : Cintre Sournois
Citation : djlixfe
Je suis désolé @bluestorm, mais le NULL est très important.
L'intérêt principal est de marquer l'absence de valeur.
Non.
Il est tout a fait possible de concevoir une BDD sans aucun NULL.
L'absence de valeur ça se gère au niveau conceptuel.
Si tu penses ne pas connaître la date de naissance, tu la sort dans une table.
per_id nom prenom
1 DURANT Paul
2 DUPONT Jean
3 KOSARZY Pierre
per_id dateNaiss
2 1983-01-01
Tu peux en faire une vue pour tout récupérer simplement:
CREATE VIEW vue_personne AS
SELECT per_id, nom, prenom, COALESCE(dateNaiss, 'inconnu') AS dateNaiss
FROM personne
NATURAL LEFT JOIN dateNaiss
per_id nom prenom dateNaiss
1 DURANT Paul inconnu
2 DUPONT Jean 1983-01-01
3 KOSARZY Pierre inconnu
Les âmes sensibles diront que ça fait "beaucoup de table", il y a "beaucoup de jointures" donc c'est compliqué et pas performant.
Ça ne tient pas debout.
Soit l'on travail sans NULL, soit on fait avec, et bonne chance.
Rappel: dans la Théorie Relationnelle, de laquelle s'inspire le SQL et donc toute l'industrie des SGBD actuels, NULL n'existe pas, ça n'a aucun sens.
cela deviendra vite compliqué avec une petite vingtaine de tables.
C'est ce que je disais.
Tu fais dans l'émotionnel, aucun intérêt.
Citation : djlixfe
2- tu utilises "coalesce" dans ta vue pour contourner le NULL utilisé par LE SGBD pour marquer son absence de valeur (tiens tiens) dans un résultat donné. (Cela semble bizarre d'utiliser cela pour éviter les NULL).
Le fait est que j'ai éradiqué NULL des tables.
Je n'ai que de l'information et pas de la pollution.
Pour l'affichage à l'utilisateur j'utilise COALESCE pour lui présenter "inconnu", certainement plus parlant qu'une chaine de caractère vide ou NULL. C'est nécessaire à cause de la jointure externe, je n'y peux rien.
Citation : djlixfe
3- le fondateur de la théorie relationnelle (Dr CODD) a établit 12 règles pour définir ce qui est exigé d'un système de gestion de base de données (SGBD)
Règle 3 : Traitement des valeurs nulles :
Le système de gestion de bases de données doit permettre à chaque champ de demeurer nul (ou vide). Spécifiquement, il doit soutenir une représentation "d'information manquante et d'information inapplicable" qui est systématique, distincte de toutes les valeurs régulières (par exemple, "distincte de zéro ou tous autres nombres," dans le cas des valeurs numériques), et ce indépendamment du type de données. Cela implique également que de telles représentations doivent être gérées par le système de gestion de bases de données d'une manière systématique.
sur ce point rien à commenter il a tout dit.
La Théorie Relationnelle évolue.
Et Ted Codd se trompe sur ce point.
Des auteurs comme Chris Date ont montré que NULL était tout à fait inutile et n'a aucun sens.
Une relation, par définition, ne peut pas accepter NULL. http://www.developpez.net/forums/d8369 [...] /#post4805060
ce genre de traitement est couteux en performances et en stockage (personne ne pourra le nier)
Oui je suis d'accord que l'on peut contourner l'utilisation du marqueur NULL, mais ce que je n'arrive pas à cerner c'est le pourquoi du refus d'utiliser NULL. Quoi de plus naturel d'accepter l'absence de valeurs!
concernant ton utilisation de coalesce, en fait je tenais tout simplement à souligner l'ironie de la situation : tu essayes de contourner le NULL en utilisant une expression qui remplace dans une requête un marqueur NULL par une valeur conventionnelle. (il faut reconnaitre qu'il y'a de quoi s'étonner)
Concernant l'évolution de la théorie, Chris Date affirme que Codd se trompe mais d'autres affirment que c'est le contraire.
ce genre de traitement est couteux en performances et en stockage (personne ne pourra le nier)
Prouve-le.
Citation : djlixfe
Oui je suis d'accord que l'on peut contourner l'utilisation du marqueur NULL, mais ce que je n'arrive pas à cerner c'est le pourquoi du refus d'utiliser NULL. Quoi de plus naturel d'accepter l'absence de valeurs!
Donc tu n'as rien compris
Citation : djlixfe
Concernant l'évolution de la théorie, Chris Date affirme que Codd se trompe mais d'autres affirment que c'est le contraire.
Source ?
Tu t'intéresses un peu à la théorie relationnelle ? Moi oui.
Et c'est un fait.
Par définition même, tu sais ce qu'est une relation ? NULL n'existe pas au pays des relations.
Oui je suis d'accord que l'on peut contourner l'utilisation du marqueur NULL, mais ce que je n'arrive pas à cerner c'est le pourquoi du refus d'utiliser NULL. Quoi de plus naturel d'accepter l'absence de valeurs!
Je refuse l'absence de valeur parce que justement, l'absence de valeur n'est pas une valeur. Je n'ai pas envie de devoir me demander à chaque fois que je récupère des données "est-ce que ce sont de vraies données, ou un NULL ?".
Il y a des applications où on a envie de dire "cette donnée n'est pas toujours présente". Dans ce cas, on utilise en fait un autre type : le type de "soit un entier, soit rien" (je prends un entier comme exemple, ça peut aussi être "soit une chaîne, soit rien").
NULL n'est pas un entier. Par contre NULL appartient au type "soit un entier, soit NULL".
Dans les langages de programmation modernes, on a moyen de représenter ces types. Comme je l'ai déjà dit :
Citation
Si le langage des types de SQL n'était pas si pauvre (pas de type somme/union), on pourrait même s'en débarasser complètement en définissant un type explicite pour les champs pouvant ne pas avoir de valeur, comme les option/Maybe des langages ML.
Dans un langage ML (comme Objective Caml) on peut dire par exemple :
type entier_ou_rien =
| Vrai_entier of int
| Rien
Une valeur de ce type est soit un "vrai entier", marqué par le constructeur Vrai_entier (par exemple Vrai_entier 2), soit Rien. Le point important c'est que ce type est différent du type des entiers : on ne peut pas se tromper en utilisant l'un à la place de l'autre. On n'a jamais de choix bidons à faire du style "dans NULL*k, on renvoie NULL, 0 ou k ?", car on n'a pas le droit de multiplier les "entier_ou_rien", seulement les entiers.
On peut avoir un type plus général qui est "soit un type, soit rien" :
type 'a option =
| Some of 'a
| None
Some 1 est de type int option, Some true de type bool option, etc.
Pour pouvoir représenter ça, il faut une union disjointe au niveau des types : "un élément est soit de la forme machin, soit de la forme truc, et je sais laquelle des deux". On peut avoir quelque chose d'approchant en C par exemple en combinant une union dans une struct.
En SQL, on peut faire des types produits/composés, mais pas des types sommes/union. Si on pouvait le faire, on pourrait définir ces types de "une valeur ou rien", et on les mettrait explicitement dans la table. On n'aurait pas besoin de NULL.
L'idée d'avoir un type explicite au lieu de NULL qui est implicite, c'est qu'on contrôle beaucoup mieux ce qui peut ne pas avoir de valeur. On est sûr qu'on ne peut pas confondre et laisser un NULL "s'échapper" parmis les valeurs normales, puisqu'elles ont des types différents.
NULL est une facilité qui pose plus de problème qu'il n'en résoud. Toutes les opérations se retrouvent à devoir gérer NULL et ont des comportements incohérents, ce qui provoque de nombreux bugs.
Un sujet de discussion proche est la question des pointeurs NULL dans les langages de programmation. Leur inventeur (Tony Hoare), a changé d'avis, et appelle maintenant le concept de pointeur NULL sont erreurd'un milliard de dollars, en référence à l'argent perdu dans les nombreux bugs qu'il a provoqués.
Par ailleurs, dans PostgreSQL, NULL pose des erreurs de typage atroces. C'est plus un problème de PostgreSQL (qui essaie de vérifier les types, mais ne le fait pas de façon assez puissante), mais ça reste un des problèmes pénibles liés à NULL.
Remarque : on pourrait penser à premier abord que le type somme/union que je propose pour les valeurs nullable a un coût en performance, puisqu'il faut faire à chaque fois un test pour retrouver la "vraie valeur" quand il y en a une. En réalité, la présence de NULL dans tous les types a déjà un coût de performance, puisque les SGBD sont déjà obligées de trouver une représentation pour NULL, et les opérations doivent faire à chaque fois des tests pour vérifier qu'on ne leur donne pas NULL. Tous ces tests coûtent en performance. Si on enlevait complètement NULL pour le remplacer par ces types somme/union, on devrait toujours faire des tests sur ces types, mais seulement sur les types qu'on a choisi comme annulables, qui sont en pratique très peu nombreux si la BDD est bien conçue. On gagnerait en performance sur tous les types qui se retrouveraient réellement non-nullables, et dont les opérations n'auraient plus besoin de ces vérifications.
En SQL, NULL n'est pas à remplacer par quoique ce soit, mais à supprimer.
Puisqu'il est inutile, n'a aucun sens, est source d'erreur.
Mais c'est trop tard.
Espérons qu'à l'avenir les SGBDR utiliseront des langages réellement Relationnels comme Tutorial D et abandonnerons le SQL.
la valeur null
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Mon site - Mon livre sur le XML - Mon blog
Mon site - Mon livre sur le XML - Mon blog
Mon site - Mon livre sur le XML - Mon blog