Supposons que x code> est une variable qui a une valeur autre que null code>, par exemple, comme exemple. Que devrait renvoyer l'expression suivante? x != null
4 Réponses :
Bien dans les moteurs SQL, vous n'utilisez généralement pas l'opérateur "=", mais "est", qui le rend alors plus intuitif.
SELECT 4 IS NULL FROM dual; > 0 SELECT 4 IS NOT NULL FROM dual; > 1
Je suis conscient que l'opérateur NULL est (non) NULL, cela ne répond pas vraiment à ma question; Je demande pourquoi ! = fonctionne comme ça, pas sur les moyens de travailler autour de son comportement étrange
La raison en est que le concept d'égalité ne s'applique pas à NULL. Il n'est pas logiquement vrai de dire que cette nulle fait ou ne correspond pas à cette autre nulle.
Donc, tout va bien pour une raison théorique, mais pour des raisons de commodité, pourquoi SQL ne permet pas à votre de dire (x! = null)?
Eh bien, la raison est parce que parfois vous voulez gérer les nulles différemment. Si je dis (Columna = colonne), par exemple, devriez-vous renvoyer true si les deux colonnes sont nuls? Si je dis (Columna! = Columnb) - Devriez-le donner le même résultat lorsque la colonne A est "A" et la colonne B est null, et lorsque la colonne A est "A" et la colonne B est "B"?
Les personnes qui ont décidé SQL ont décidé que la distinction était importante et qu'elle l'a écrit pour traiter les 2 cas différemment.
La page Wikipedia sur cette page a une assez décente rétroduite - http: //fr.wikipedia .org / wiki / null_% 28SQL% 29
Pourquoi cette spéciale des bases de données est-elle spéciale? Pourquoi les personnes n'ont-elles pas fait le même comportement de comparaison avec des types nullables dans des langages de programmation standard?
Eh bien, si je devais deviner ... SQL est plus enraciné dans les concepts de programmation de style fonctionnel. Les langages de programmation standard sont généralement impératifs. Dans SQL, vous décrivez essentiellement le problème et laissez votre serveur DB à déterminer comment résoudre le problème. Du côté impératif, vous racontez normalement le programme comment résoudre votre problème étape par étape. Généralement, les personnes qui occupent des soins logiques fonctionnels plus profondément sur la signification sous-jacente des déclarations fonctionnelles qu'une approche impérative où nous supposons que nous pouvons dire comment résoudre le problème.
En bref: à partir d'une perspective fonctionnelle, il est plus important de pouvoir décrire avec précision votre problème.
MEH, je ne vois pas comment la différence de paradigme affecte vraiment ce problème de comparaison. Dans une langue fonctionnelle comme F #, par exemple, certains (x) <> nucle renvoie true
C'était une décision de conception. Les personnes derrière F # sont venues à une décision différente. N'oubliez pas que F # est construit sur le CLR de .NET et est donc influencé par cette expérience et les années d'expérience avec SQL et d'autres approches fonctionnelles et doivent choisir et choisir quoi utiliser. SQL a été développé il y a longtemps et ne peut pas vraiment changer de cap sur quelque chose d'aussi fondamental maintenant.
La nulle dans la plupart des langages de programmation est considérée comme "connue", tandis que NULL en SQL est considéré comme "inconnu".
x == null compare X avec une valeur connue et le résultat est connu (vrai ou faux).
- mais
x = null compare x avec une valeur inconnue et le résultat est inconnu (c'est-à-dire null, encore une fois). En conséquence, nous avons besoin d'un opérateur spécial est [non] null pour le tester.
Je suppose que au moins une partie de la motivation de ces nulls serait le comportement des clés étrangères. Lorsqu'un point final d'enfant d'une clé étrangère est NULL, il ne devrait pas correspondre à aucun parent, même si le parent est null (ce qui est possible si le parent est unique au lieu de la clé primaire). Malheureusement, cela apporte beaucoup plus Gotchas < / a> que cela résout et je pense personnellement que SQL aurait dû aller la route de la null "connue" et évitée ce commerce de singe.
Même E. F. Mody, inventeur ou modèle relationnel, a ensuite indiqué que la null traditionnelle n'est pas optimale. Mais pour des raisons historiques, nous sommes à peu près bloqués.
dans SQL, Si vous dites x! = null, vous dites "est la valeur de x inégale à une valeur inconnue". Eh bien, puisque nous ne savons pas quelle valeur inconnue est, nous ne savons pas si X est égal à celui-ci ou non. Donc, la réponse est "je ne sais pas". p> De même: P> null code> signifie "une valeur inconnue". COALESCE(NULL, 1) -- 1
COALESCE(NULL, NULL, 1) -- Also 1
COALESCE(x, y, z, 0) -- x, unless it is null, then y, unless it is null, then z, unless it is null in which case 0.
Dans SQL, NULL fait pas représente vraiment une valeur inconnue. S'il le faisait alors x = x évaluerait correctement à vrai (en mathématiques, la logique et la réalité, une valeur inconnue est certainement égale à elle-même!) La norme SQL ne définit pas le sens de null, il définit simplement sa syntaxe et ( Comportement étrange, incompatible, non mathématique). L'idée que NULL "signifie" inconnu n'est qu'une hypothèse inexacte et souvent dangereuse faite par certains praticiens SQL.
Le questionnaire cherchait un moyen de comprendre NULL, pas la définition standard SQL.
"En mathématiques, la logique et la réalité, une valeur inconnue est certainement égale à elle-même". Non. Une valeur inconnue n'est pas nécessairement égale à une autre valeur inconnue. Je ne connais pas la date de naissance de Joel Spolsky, je connais la date de naissance de Raymond Chen. Cela ne signifie pas qu'ils sont les mêmes.
Problème différent. La date de naissance de Joel Spolsky est exactement égale à la date de naissance de Joel Spolsky. Mais si la date de naissance de Joel Spolsky dans la base de données est NULL, il n'est pas égal à lui-même. C'est un exemple (parmi d'autres) de pourquoi NULL ne représente pas avec précision le cas "inconnu". Pratiquement et logiquement, c'est une idée fausse de penser que Null signifie toujours inconnu.
X! = NULL fonctionne dans de nombreuses implémentations SQL? J'ai toujours utilisé X n'est pas null.
Parce que
null est inconnu. Cela pourrait être 4. Ceci est définitivement une dupe.Une façon dont j'ai entendu dire, c'est que "NULL est un état d'être, pas une valeur".
@Martinsmith alors pourquoi ne serait-il pas la même chose dans d'autres langages de programmation?
@Peterolson - Je pense que c'est avec des types nullables dans
C #@Martinsmith non ce n'est pas.
int? x = 3; x! = null retournetrue@Peterolson: Vous obtiendrez probablement beaucoup plus d'informations de L'entrée Wikipedia sur NULL qu'ici sur Stackoverflow.
@Peterolson - Oui, je me suis souvenu de ce faux. J'ai rappelé de voir une question à leur sujet pour laquelle la réponse était de faire avec 3 logique valorisée récemment - que j'ai trouvée ici mais pas vraiment pertinent pour ce que vous demandez si
Je suppose - le résultat d'une décision historique, puis il suffit de maintenir une compatibilité en retard