Pourquoi MYSQL DANS le mot-ne pas considérer les valeurs NULL

Je suis l'aide de la requête suivante:

select count(*) from Table1 where CurrentDateTime>'2012-05-28 15:34:02.403504' and Error not in ('Timeout','Connection Error');

Étonnamment, cette déclaration ne comprend pas les lignes ayant une valeur d'Erreur NULLE.Mon intention est de filtrer uniquement les lignes avec la valeur d'Erreur comme 'Timeout' (ou les) 'Erreur de Connexion'. J'ai besoin de donner une condition supplémentaire( OU une Erreur est NULLE) pour récupérer le résultat correct.

Pourquoi est-MYSQL filtrer les résultats avec les valeurs NULL?
Je pensais que DANS le mot serait retourner un résultat booléen (1/0) et maintenant, je comprends que certains mots-clés MYSQL ne marche pas, le retour des valeurs booléennes,il peut retourner NULL....mais Pourquoi est-il traiter NULL spécial?

InformationsquelleAutor Never Back Down | 2012-05-30

mysql mysql-python

24

Ce :
```
Error not in ('Timeout','Connection Error');
```
est sémantiquement équivalent à:
```
Error <> 'TimeOut' AND Error <> 'Connection Error'
```
Règles à peu près nulle comparaison s'applique à DE trop. Donc, si la valeur de l'Erreur est NULLE, la base de données ne peut pas faire l'expression véritable.

À résoudre, vous pourriez faire ceci:
```
COALESCE(Error,'') not in ('Timeout','Connection Error');
```
Ou mieux encore:
```
Error IS NULL OR Error not in ('Timeout','Connection Error');
```
Ou mieux encore:
```
 CASE WHEN Error IS NULL THEN 1
 ELSE Error not in ('Timeout','Connection Error') THEN 1
 END = 1
```
OR n'a pas de court-circuit, l'AFFAIRE peut en quelque sorte court-circuit de votre requête

Peut-être un exemple concret pourrait illustrer pourquoi NULL NOT IN expression ne retourne rien:

Compte tenu des données: http://www.sqlfiddle.com/#!2/0d5da/11
```
create table tbl
(
  msg varchar(100) null,
  description varchar(100) not null
  );


insert into tbl values
('hi', 'greet'),
(null, 'nothing');
```
Et vous faire de cette expression:
```
select 'hulk' as x, msg, description 
from tbl where msg not in ('bruce','banner');
```
Qui va afficher "salut" seulement.

Le PAS est traduit comme:
```
select 'hulk' as x, msg, description 
from tbl where msg <> 'bruce' and msg <> 'banner';
```
NULL <> 'bruce' ne peut être déterminée, même pas vrai, même pas faux

NULL <> 'banner' ne peut être déterminée, même pas vrai même pas faux

De sorte que la valeur null expression, effectivement résolu: de
```
can't be determined AND can't bedetermined
```
En fait, si votre SGBDR prend en charge booléenne sur SÉLECTIONNER(par exemple, MySQL, Postgresql), vous pouvez voir pourquoi: http://www.sqlfiddle.com/#!2/d41d8/828
```
select null <> 'Bruce' 
```
Qui retourne null.

Cette méthode retourne null trop:
```
select null <> 'Bruce' and null <> 'Banner'
```
Étant donné que vous êtes en utilisant NOT IN, qui est essentiellement un ET de l'expression.
```
NULL AND NULL
```
Résultats à NULL. C'est comme si vous faites un: http://www.sqlfiddle.com/#!2/0d5da/12
```
select * from tbl where null
```
Rien n'est retourné
- Oui, je sais, il y a un travail autour de cela.Je suis juste curieux de savoir pourquoi est ce comportement étrange?
- Il n'est pas étrange, c'est encore dans la norme ANSI SQL. Pensez à la valeur NULL comme générique, vous ne pouvez pas affirmer que NULL <> "Bonjour"; parfois, la valeur NULL est destiné à être remplacé plus tard avec une réelle valeur. C'est la façon dont je regarde. NULL a une signification spéciale dans la base de données
- Et IN / NOT IN, est sémantiquement équivalent à V = 'Alpha' OR V = 'Beta', V <> 'Alpha' AND V <> 'Beta' respectivement, donc les règles à propos de la valeur NULL s'applique toujours
- Merci Michael Buen...je suis à l'aide de python avec mysql.python renvoie 0/1 ET,OU,DANS les états, mais Mysql retourner la valeur NULL
- Peut-être l'erreur de traduction se trouve sur python côté. Je vais vérifier sur la langue qui prend en charge nullable variable
- J'ai essayé sur ADO.NET le NULL <> 'Bruce' décide de Système.DBNull, ce n'est pas 1 ni 0. Ou peut-être que je suis à l'aide de Postgres. Je pense que cela dépend de la couche d'accès aux données mécanisme de trop. Je préférerais avoir un DAL qui montre la même chose que ce que je peux voir sur le SGBD lui-même
- C'est génial!...assurez-vous
- le case when raccourci, c'est le génie
- Vous avez fait un excellent point. Vous dites dans votre post: ---------------- Erreur n'est pas dans ('Timeout','Erreur de Connexion'); est sémantiquement équivalent à: Erreur <> 'TimeOut' ET d'Erreur <> 'Erreur de Connexion' Règles à peu près nulle comparaison s'applique à DE trop. Donc, si la valeur de l'Erreur est NULLE, la base de données ne peut pas faire l'expression de vrai. ----------------- Et dans dev.mysql.com/doc/refman/5.6/en/type-conversion.html j'ai trouvé cette phrase qui confirme votre déclaration: "Si l'un ou les deux arguments sont NULL, le résultat de la comparaison est NULLE, sauf pour les NULS-safe <=> l'égalité opérateur de comparaison."
InformationsquelleAutor Michael Buen
1

Parce que null n'est pas défini null n'est pas égal à null. Vous devez toujours traiter explicitement la valeur null.

InformationsquelleAutor Karl
1

IN retourne NULL si l'expression sur le côté gauche est NULL. Afin d'obtenir le NULL valeurs, que vous avez à faire:
```
select count(*) from Table1 where CurrentDateTime>'2012-05-28 15:34:02.403504' and (Error not in ('Timeout','Connection Error') or Error is null);
```
- Ouais, je l'ai mentionné, c'est la question elle-même.Je voulais juste savoir pourquoi ce comportement étrange?
InformationsquelleAutor ziad-saab

IN renvoie une trivalent BOOLEAN (qui n'accepte NULL comme une valeur). NOT IN renvoie la trivalent négation de IN, et de négation de NULL est un NULL.

Imaginer que nous avons un tableau avec tous les numéros de 1 à 1,000,000 dans id et cette requête:

SELECT  *
FROM    mytable
WHERE   id IN (1, 2, NULL)

ou son équivalent:

SELECT  *
FROM    mytable
WHERE   id = ANY
             (
             SELECT  1
             UNION ALL
             SELECT  2
             UNION ALL
             SELECT  NULL
             )

Le prédicat retourne TRUE pour 1 et 2 et NULL pour toutes les autres valeurs, donc 1 et 2 sont retournés.

Dans son ci-contre:

SELECT  *
FROM    mytable
WHERE   id NOT IN (1, 2, NULL)

SELECT  *
FROM    mytable
WHERE   id <> ALL
             (
             SELECT  1
             UNION ALL
             SELECT  2
             UNION ALL
             SELECT  NULL
             )

le prédicat retourne FALSE pour 1 et 2 et NULL pour toutes les autres valeurs, donc, rien n'est retourné.

Noter que la négation booléenne pas seulement les changements de l'opérateur (= à <>), mais le quantificateur trop (ANY à ALL).

InformationsquelleAutor Quassnoi

0

@Michael Buen ' s réponse était la bonne réponse pour mon cas, mais permettez-moi de simplifier pourquoi.

@Michael a dit dans son post:

Erreur n'est pas dans ('Timeout','Erreur de Connexion');

est sémantiquement équivalent à:

Erreur <> 'TimeOut' ET d'Erreur <> 'Erreur de Connexion'

Règles à peu près nulle comparaison s'applique à DE trop. Donc, si la valeur de l'Erreur est NULLE, la base de données ne peut pas faire l'expression véritable.

Et dans [1] j'ai trouvé cette phrase qui confirme son plus important pour comprendre le pourquoi DE l'échec avec la valeur NULL. Dans le cahier des charges ("caractéristiques") dans [1], vous aurez à: "Si l'un ou les deux arguments sont NULL, le résultat de la comparaison est NULLE, sauf pour les NULS-safe <=> l'égalité opérateur de comparaison."

Donc oui, la chose est que, malheureusement, Mysql se perd dans un tel cas. Je pense que Mysql concepteurs ne devais pas faire cela, parce que quand je compare les 2 NULL, Mysql DEVRAIT être en mesure de voir qu'ils sont DIFFÉRENTS, et pas simplement jeter erronée des résultats. Par exemple, j'ai fait:
```
select id from TABLE where id not in (COLUMN WITH NULLS);
```
puis il jette des résultats VIDES. MAIS. Si je ne
```
select id from TABLE where id not in (COLUMN WITH OUT NULLS);
```
il montre le bon résultat. Donc, lorsque vous utilisez l'opérateur, vous devez filtrer les valeurs NULL. Ce n'est pas un comportement souhaité pour moi en tant qu'utilisateur, mais c'est documenté dans le cahier des charges [1]. Je pense que les langues et la technologie devraient être plus simples, dans le sens que vous devriez être en mesure de DÉDUIRE sans avoir besoin de lire les specs. Et vraiment, 2 est DIFFÉRENT de NULL, je dois être l'un en charge de contrôler et de prendre soin des erreurs d'un niveau d'abstraction plus élevé, mais MySQL DEVRAIT jeter un résultat FAUX lorsque l'on compare les valeurs NULL avec une valeur spécifique.

Références pour les specs: [1] http://dev.mysql.com/doc/refman/5.6/en/type-conversion.html

InformationsquelleAutor David L
0

Désolé de poster deux fois dans le même forum, mais je veux illustrent un autre exemple:

Je suis d'accord avec @Wagner Bianchi dans [2] dans ce forum, quand il dit:
<< C'est très astuce lorsque vous traitez avec des données et les sous-requêtes>>

En outre, cela ne devrait PAS être le problème, je pense que Mysql, les designers sont dans l'erreur quand ils ont pris cette décision documenté dans [1]. La conception doit être différent. Laissez-moi vous expliquer: Vous savez que lorsque l'on compare les
```
select (2) not in (1, 4, 3);
    you will get:
        +----------------------+
        | (2) not in (1, 4, 3) |
        +----------------------+
        |                    1 |
        +----------------------+
        1 row in set (0.00 sec)
```
MAIS si dans la liste, vous avez au moins un NUL, alors:
```
select (2) not in (1, NULL, 3);
    throws:
        +-------------------------+
        | (2) not in (1, NULL, 3) |
        +-------------------------+
        |                    NULL |
        +-------------------------+
        1 row in set (0.00 sec)
    This is pretty absurd.
```
Nous ne sommes pas les premiers à obtenir confus par ce. Voir [2]

Références:

[1] http://dev.mysql.com/doc/refman/5.0/en/comparison-operators.html#function_in

[2] http://blog.9minutesnooze.com/sql-not-in-subquery-null/comment-page-1/#comment-86954

InformationsquelleAutor David L

Vous devez vous connecter pour publier un commentaire.

Règles à peu près nulle comparaison s'applique à DE trop. Donc, si la valeur de l'Erreur est NULLE, la base de données ne peut pas faire l'expression véritable.