Retour inattendu d'un select

Retour inattendu d'un select - SQL/NoSQL - Programmation

Marsh Posté le 10-07-2009 à 22:27:10    

Bonjour,
 
J'ai une requête qui me retourne quelque chose que je n'arrive pas à comprendre. J'utilise MySQL v5.0.81 sous Debian :
 

Code :
  1. mysql> SELECT * FROM devices WHERE id = 259;
  2. +-----+----------------+-------------+---------------+---------------------+---------------------+
  3. | id  | workstation_id | resource_id | resource_type | created_at          | updated_at          |
  4. +-----+----------------+-------------+---------------+---------------------+---------------------+
  5. | 259 |           NULL |         259 | Screen        | 2009-07-08 18:06:01 | 2009-07-08 18:06:01 |
  6. +-----+----------------+-------------+---------------+---------------------+---------------------+
  7. 1 row IN SET (0.00 sec)
  8.  
  9. mysql> SELECT * FROM devices WHERE workstation_id = NULL;
  10. Empty SET (0.00 sec)


 
Quelqu'un pourrait m'expliquer pourquoi la ligne n'est pas retournée par la deuxième requête? (Je précise qu'aucun delete/update n'a été fait entre les 2 requêtes)
 
Merci bien


---------------
Si la vérité est découverte par quelqu'un d'autre,elle perd toujours un peu d'attrait
Reply

Marsh Posté le 10-07-2009 à 22:27:10   

Reply

Marsh Posté le 10-07-2009 à 22:31:31    

Il me semble qu'habituellement, on écrit "is null" plutôt que "= null".

Reply

Marsh Posté le 10-07-2009 à 22:35:43    

ça résout le problème, désolé pour la question débile..
Par contre, une idée de pourquoi = NULL ne génère pas d'erreur mais ne detourne pas la même chose que is null?
 
merci


---------------
Si la vérité est découverte par quelqu'un d'autre,elle perd toujours un peu d'attrait
Reply

Marsh Posté le 10-07-2009 à 23:08:00    

Je pense que la raison est triple.
 
Premièrement, les auteurs du SQL n'ont pas eu comme objectif prioritaire de faciliter la vie des programmeurs, mais à faire quelque chose de logique (sinon, ils auraient donné la même syntaxe à l'insert et à l'update ; ils auraient aussi inventé une seule instruction pour faire le insert-or-update ; ils auraient inventé le select étoile sauf certain champs ; etc." )
 
Deuxièmement, au niveau interne, pour une colonne qui peut être nulle, elle est définie comme étant une structure qui contient un booléen null/not-null, et une chaine de caractères ou un nombre pour contenir sa valeur. Donc quand il y a un "=", le programme va regarder le contenu de la chaine de caractères ou du nombre, mais ne va pas regarder le flag null/not-null. Par contre, quand le programme voit "is null", le programme va regarder le flag sans regarder le contenu. La syntaxe "= null" pourrait être comprise comme une comparaison du contenu avec quelque chose de nul, mais cela n'aurait pas de sens, car c'est le flag qui compte.
 
Troisièmement, si les tables sont créées en respectant strictement les règles de E. Codd, alors il ne devrait y avoir que très peu de champs nuls dans une base de données.


Message édité par billgatesanonym le 10-07-2009 à 23:11:27
Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed