Discussion :

[keokaz]

Bonsoir je n'arrive pas à trouver la bonne requête pour supprimer le tuple qui possède NULL :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
MariaDB [immo]> select * from transaction;
+-------------+-------------+
| id_logement | id_acheteur |
+-------------+-------------+
|           1 |           3 |
|        NULL |           3 |
+-------------+-------------+
2 rows in set (0.00 sec)
 
MariaDB [immo]>

mais avant est t'il possible de le faire malgré qu'il n'y pas de clés primaire?

merci de votre réponse

[sevyc64]

Il n'y a aps de raison que ce ne soit pas possible dès le mooment ou il peut être identifié de manière unique.

Je connais pas MariaDB, mais je dirais

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 DELETE FROM TRANSACTION WHERE ID_LOGEMENT IS NULL AND ID_ACHETEUR=3

[keokaz]

Merci de ta réponse

c'est la requête que j'ai essayer:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
MariaDB [immo]> delete  from transaction where `id_logement` = NULL AND `id_acheteur` = 3;
Query OK, 0 rows affected (0.00 sec)
 
MariaDB [immo]> select * from transaction;
+-------------+-------------+
| id_logement | id_acheteur |
+-------------+-------------+
|           1 |           3 |
|        NULL |           3 |
+-------------+-------------+
2 rows in set (0.00 sec)

pour les requetes simple mariadb et mysql c'est doit être la même chose ?
le tuple 2 est toujours là ??

Est ce qu'une telle table de clé étrangère a besoin d'un champs clé primaire à incrémenter ?(ce qui pourrais contourner le problème en mettant where id_transaction = 2)

ou il y a un problème sur 'NULL', peut t'on (je ne l'ai jamais fait) testé le type de NULL si le NULL de la table id_logment et bien le même NULL de la requête (c'est tordu ...)

[sevyc64]

A ma connaissance NULL, c'est NULL, pas autre chose (oui je sais, c'est assez NULL nul comme formule ). Après, je ne sais pas si MariaDB (ou même mySql) a des spécificités sur ce point.

Après, pour tester si c'est null, j'ai souvent vu dans les SGBD utilisé l'opérateur IS NULL, et non pas = NULL comme tu l'écris. Il n'est pas impossible qu'il y ait un comportement différent entre les 2 écritures.

Est ce qu'une telle table de clé étrangère a besoin d'un champs clé primaire à incrémenter ?

A priori non.
De ce que comprend, ta table est une table association. Même si tu n'as pas déclarer de clé primaire, il y en a une pseudo par le couple des 2 id (des 2 clés étrangères). Et tu pourrais très déclarer ce couple comme étant la clé primaire, une clé composée de fait.
La seule différence entre déclarer la clé ou ne pas le déclarer c'est que la clé primaire impose une contrainte d'unicité (ici, tu ne pourrais pas avoir 2 couples identiques avec la clé composée), une contrainte de non nullité (tu ne pourrais pas avoir un couple nul, ce qui ne veut pas dire que tu ne peux pas avoir de coulpe avec un élément nul, attention) et généralement ajoute aussi un index sur cette clé.

Mais normalement (encore une fois, je ne sais pas pour MariaDB), une clé primaire n'est absolument pas obligatoire pour supprimer un tuple. Il faut juste que le tuple puisse être identifié de façon certaine par le filtre (et si le filtre identifie plusieurs tuples, c'est tous les tuples identifiés qui sont supprimés)

[al1_24]

c'est la requête que j'ai essayer:
[CODE]MariaDB [immo]> delete from transaction where `id_logement` = NULL AND `id_acheteur` = 3;

L'expression `id_logement` = NULL ne sera jamais vraie !
Ce qu'il faut mettre dans la clause WHERE c'est id_logement IS NULL, et c'est bien ce que sevyc64 proposait dans sa requête.

[Artemus24]

Salut keokaz.

NULL n'est pas une valeur, c'est plutôt le contraire, c'est l'absence de valeur et de ce fait, on le qualifie de marqueur.

Donc si vous faites "ID_LOGEMENT = NULL", vous testez la valeur NULL et de ce fait, le résultat de votre requête ne fonctionnera jamais.
Tandis que la bonne écriture est de mettre "ID_LOGEMENT IS NULL" car ici vous testez le marqueur NULL.

A lire en urgence : http://sqlpro.developpez.com/cours/null/

@+

[keokaz]

Merci , j'avais lu la réponse IS NULL mais j'avais pas testé(mauvais copier coller),
cela fonctionne:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
delete  from transaction where `id_logement` IS NULL AND `id_acheteur` = 3;

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
MariaDB [immo]> delete  from transaction where `id_logement` IS NULL AND `id_acheteur` = 3;
Query OK, 1 row affected (0.08 sec)
 
MariaDB [immo]> select * from transaction;
+-------------+-------------+
| id_logement | id_acheteur |
+-------------+-------------+
|           1 |           3 |
+-------------+-------------+
1 row in set (0.00 sec)

c'est vrai que est égale à rien du tout le moteur ne peux pas comparer , j'ai pas du utiliser beaucoup ce terme "IS", on l'utilise que avec IS NULL ou on
peut l'utiliser avec autre chose ?

et d'ailleur il y a des injections SQL qui utiliser ce NULL ? on pourrais imaginer une requête qui n'aboutirais jamais ?

(sinon on n'a tellement tendance à utiliser phpmyadmin et suprimer par des boutons qu'on n'avance jamais sur la base de données)

[Artemus24]

Salut keokaz.

A ma connaissance, le "is" s'utilise qu'avec le NULL.
L'écriture doit être différente car le NULL est un marqueur et non une valeur.
Par contre, en ce qui concerne MySql et MariaDB, c'est l'absence d'erreur sur "= NULL", ce qui n'est pas normal d'un point de vue syntaxique.

@+

[keokaz]

Merci,

c'est vrai, le moteur devrais retourner une erreur genre je ne peux pas évaluer quelque chose qui n'existe pas ,
par ce que si je vais ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
delete  from transaction where `id_logement` = AND `id_acheteur` = 3;

j'ai tout de suite une erreur.

D'ailleur je me demande ce que ça donne chez postgresql ? car ça peut être générer l'erreur puisque apparemment postgresql encore plus rigoureux ...

[Artemus24]

Salut keokaz.

Non, il s'agit bien d'une erreur de syntaxe car la condition sur un NULL s'écrit soit "IS NULL" ou soit "IS NOT NULL" mais pas autrement.
De ce coté là, MySql et MariaDB autorisent ce que la norme n'acceptent pas.

@+

[al1_24]

Il n'y a pas de raison pour qu'une erreur de syntaxe soit émise lors du test colonne = NULL.
Cette expression est tout à fait valide et, comme la majorité des expressions impliquant un NULL, est évaluée à... NULL.
Or NULL n'est pas une expression logique ; de ce fait il n'est ni vrai ni faux. Utilisée dans la clause WHERE, l'expression colonne = NULL est reconnue comme non vraie (je n'ai pas dit fausse !) et la requête ne retourne aucune ligne.
Si une erreur de syntaxe devait être émise chaque fois qu'une expression de type <valeur> = NULL est interprétée, il serait impossible de comparer deux expressions dont l'une pourrait être évaluée à NULL.

[Artemus24]

Salut Al1_24.

Il n'y a pas de raison pour qu'une erreur de syntaxe soit émise lors du test colonne = NULL.

Non, non et non. Vous confondez valeur et marqueur.
NULL n'est pas une valeur mais un marqueur, donc cela ne doit pas se tester de la même façon.

Or l'exemple donné par colonne = NULL traite le NULL comme une valeur, donc c'est aberrant.
Car une absence de valeur ne peut pas se traiter comme une valeur.

Et ce n'est pas parce que MySql tolère ce genre d'écriture, que MySql à raison !

C'est pourquoi il existe un autre opérateur pour faire le test colonne IS NULL.
Et dans ce cas là, il s'agit de tester le marqueur, qui je le rappelle n'est pas une valeur.

A lire en urgence : http://sqlpro.developpez.com/cours/null/

@+

[sevyc64]

En réalité vous avez tous les 2 raisons.

Dans l'expression WHERE colonne = NULL, dans certains SGBD cela ne génèrera pas d'erreurs car il n'y a pas intrinsèquement d'erreur de syntaxe (en fait ceux qui génèrent une erreur vérifie explicitement ce cas là). L'écriture est correct.
Seulement, à l’exécution, plus exactement à l'évaluation de l'expression, celle-ci ne peut pas être évaluée parce que justement NULL n'est pas une valeur. Et là effectivement il y a 2 écoles, soit le SGBD plante sur l'évaluation et génère donc un exception à l’exécution, soit le SGBD, ne pouvant pas évaluer l'expression, comme le dit al1_24, ne peut donc pas l'évaluer à Vrai, il renverra donc simplement Faux sans broncher.

Certains SGBD n'accepte pas la syntaxe = NULL et génère une erreur avant exécution, certains ne savent pas l'évaluer et donc génère une exception à l’exécution, d'autres s'en accommodent répondant un résultat qui peut être (et est la plupart du temps) indéterminé.

[Artemus24]

Salut sevyc64.

Il ne s'agit pas d'avoir raison ou tort. Il s'agit du respect d'une convention qui n'est pas toujours bien comprise.

Si l'on met WHERE colonne = NULL, en toute logique ce qui suit après l'égale est considérée comme une valeur.
Or comme cette valeur n'en est pas une, la condition peut être considéré comme indéterminée.
Or "indéterminé" dans la logique binaire n'a aucun sens car seul les valeurs "vrai" ou faux" sont autorisées.
Donc sur ce point de vue, il y a un problème d'interprétation qui peut porter à confusion.
Soit on fait une logique binaire, soit une logique ternaire, mais pas les deux à la fois !

Inversement WHERE colonne IS NULL ne teste pas le contenu de la colonne "colonne", mais teste un marqueur afin de savoir s'il y a effectivement une valeur de renseignée ou pas dans cette colonne.
Le choix qui est fait par les SGBDR leur appartient et je ne viendrais pas ici débattre de ce qui est pertinent ou pas.

Et c'est là, la grande ambiguïté de gérer parfois le NULL comme un marqueur et parfois comme une valeur, dans une logique dite ternaire.

Pourquoi faire cette distinction ?
Le problème vient de la représentation de ce null (code ascii 00) et le fait que dans certaines représentation numérique, cette valeur signifie zéro.
C'est le cas des types dit entier (integer, smallint, tinyint), où justement le zéro ce code de la même façon que le NULL.
Alors on ne sait pas faire la distinction entre le zéro qui est une valeur et le null qui est l'absence de valeur, et auraient la même représentation en mémoire.

Pour ce faire, nous devons utiliser deux zones, l'une pour le marqueur et l'autre pour la valeur stockée.
D'où le fait d'avoir deux opérateurs différents pour faire cette distinction.

@+

[SQLpro]

Dans l'expression WHERE colonne = NULL, dans certains SGBD cela ne génèrera pas d'erreurs car il n'y a pas intrinsèquement d'erreur de syntaxe (en fait ceux qui génèrent une erreur vérifie explicitement ce cas là). L'écriture est correct.

Non, la norme est très claire à ce sujet.
L'expression MaColonne = NULL est parfaitement légale et doit être acceptée sans broncher pour tous les SGBDR SQL.
En effet que se passerait-il si nous avions :
MaColonne = MonAutreColonne
et que MonAutreColonne contienne un NULL ?

Dans un prédicat, une telle expression ne vaut pas vrai ni faux, mais inconnu (valeur SQL UNKNOWN !) Et cette valeur UNKNOWN fait intégralement partie de la norme SQL.
Or un prédicat est valide s'il renvoi vrai, dans les deux autres cas (FALSE ou UNKNOWN) il est invalide.
C'est le principe de la logique trivaluée de M. Codd !

Exemple avec un WHERE :

1) soit la table suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
CREATE TABLE T_SOCIETE (ENSEIGNE VARCHAR(32));
 
INSERT INTO T_SOCIETE VALUES ('la Samaritaine');
INSERT INTO T_SOCIETE VALUES ('Auchan');
INSERT INTO T_SOCIETE VALUES (NULL);

Comportant 3 lignes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT COUNT(*) FROM T_SOCIETE

2) La requête suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT * FROM T_SOCIETE WHERE ENSEIGNE LIKE '%e%';

Renvoie une seule ligne. Et c'est normal.

3) On s'attendrait à ce que la requête complémentaire suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT * FROM T_SOCIETE WHERE ENSEIGNE NOT LIKE '%e%';

ou encore :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT * FROM T_SOCIETE WHERE NOT ENSEIGNE  LIKE '%e%';

Donne deux lignes... mais la présence du null rend le prédicat WHERE ni vari ni faux.

Le vrai complément est alors :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT * FROM T_SOCIETE WHERE ENSEIGNE NOT LIKE '%e%' OR ENSEIGNE IS NULL;

Mais certains SGBDR se comporte anormalement avec le NULL...

Extrait de la norme SQL, document "foundation" :

"
<boolean literal> ::= TRUE | FALSE | UNKNOWN
The truth value of a <boolean literal> is True if TRUE is specified, is False if FALSE is specified, and is Unknown if UNKNOWN is specified.

1) Let XV and YV be two values represented by <value expression>s X and Y, respectively. The result of:
X <comp op> Y
is determined as follows:
Case:
a) If either XV or YV is the null value, then
X <comp op> Y
is Unknown.
b) Otherwise ...


If ESCAPE is not specified and either MCV or PCV are null values, then the result of
MC LIKE PC
is Unknown.
...
"


A +

[sevyc64]

Si l'on met WHERE colonne = NULL, en toute logique[...]
Soit on fait une logique binaire, soit une logique ternaire, mais pas les deux à la fois !

Sauf que justement, dans le cas de la clause WHERE, la logique n'est pas binaire ou ternaire.

La seule logique respectée dans la clause WHERE, c'est Evalué à VRAI !
Tout le reste est rejeté, que ce soit parce que c'est évalué à faux, parce que ce n'est pas évaluable, ou autre.

Non, la norme est très claire à ce sujet.
L'expression MaColonne = NULL est parfaitement légale et doit être acceptée sans broncher pour tous les SGBDR SQL.

Oui, mais les SGBD qui respectent scrupuleusement la norme ....

Certains scrutent spécifiquement la construction = NULL pour rejeter la requête à la construction, sans pour autant broncher sur = MonAutreColonne avec MonAutreColonne contenant un NULL
Certains acceptent la syntaxe mais plante à l'évaluation.
Je veux pas dire de bêtises mais il me semble que un des ces 2 cas là, je l'ai eu sur des versions ancienne d'Access, 97 je pense (Oui je sais parlais de SGBD à la base )
Mais la plupart des SGBD acceptent effectivement cette construction, mais en renvoyant parfois des résultats plus que surprenant.
D'où la difficulté de retrouver l'erreur car il n'y a pas d'erreur et le = NULL n'est pas forcément toujours facilement visible dans une grosse requête.

C'est un peu comme le classique coup de la jointure externe avec une clause sur un des champs joint dans le WHERE, la transformant de fait en jointure interne. Ya pas d'erreur en soi, mais pour trouver le problème ...

[Artemus24]

Salut à tous.

Sauf que justement, dans le cas de la clause WHERE, la logique n'est pas binaire ou ternaire.

Vous vous trompez en disant que c'est ni une logique binaire, ni une logique ternaire.
Ce qui défini la logique binaire, c'est que l'ensemble de définition d'une variable admet que deux valeurs VRAI ou FAUX.
Tandis qu'une logique ternaire admettra trois valeurs possibles : VRAI ou FAUX ou INCONNU.

Ce qui me dérange dans la logique ternaire, c'est que cela n'apporte rien de plus vis-à-vis de la logique binaire.

Même si je comprends parfaitement en quoi la logique ternaire consiste, quand je raisonne logique, je ne connais que l'algèbre de Bool et rien d'autre.
Donc un prédicat à "inconnu", et bien je ne sais pas ce que cela veux dire, vu que je m'attends à VRAI ou FAUX et seulement cela.

Autant ignorer la ligne lorque le marqueur est à NULL quand on fait un test de valeur : "WHERE colonne = {valeur}".
Inversement, si je teste le marqueur NULL alors la ligne sera sélectionnée : "colonne IS NULL".

Pour moi, "WHERE colonne = {valeur}" ne traite que des valeurs et rien d'autre.
Dans l'exemple donné par SQLPRO, si en plus de cette valeur, je désire obtenir les lignes ayant "colonne" à NULL, alors j'écris :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

WHERE colonne = {valeur} OR colonne IS NULL

J'ai ici deux prédicats :
--> colonne = {valeur}.
--> colonne IS NULL.
Chaque prédicat me donne soit VRAI soit FAUX.
Et WHERE colonne = {valeur} OR colonne IS NULL me donnera aussi comme résultat VRAI ou FAUX.

La seule logique respectée dans la clause WHERE, c'est Evalué à VRAI !

Il ne s'agit pas de cela.
Il s'agit de se poser la question si mettre "WHERE colonne = NULL" est syntaxiquement correcte ou pas.
Pour moi, c'est une erreur d'écrire cela car, je le répète encore une fois, NULL n'est pas une valeur mais un marqueur.
Donc il faut utiliser un autre opérateur qui dans ce cas là, est le "IS.

@ SQLPRO : en quoi la logique ternaire est une amélioration vis-à-vis de la logique binaire ?
Ce qui me choque, c'est cette écriture :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<boolean literal> ::= TRUE | FALSE | UNKNOWN

où "UNKNOWN est traité comme une valeur alors que dans les SGBDR, c'est remplacé par NULL qui est un marqueur.

Par quel miracle, on passe d'une valeur dite "UNKNOW", qui selon moi est une valeur et doit être traité en tant que telle, au marqueur "NULL" qui est l'absence de valeur et donc ne peut pas être traité comme une valeur ?

@+

[SQLpro]

Ce qui me dérange dans la logique ternaire, c'est que cela n'apporte rien de plus vis-à-vis de la logique binaire.

Ben justement si !
Voir ma démo : https://www.developpez.net/forums/d1...e/#post8940173

table de vérité :

Positif :
prédicat vaut vrai => WHERE retient la ligne
prédicat vaut faux => WHERE ne retient pas la ligne
prédicat vaut INCONNU => WHERE ignore la ligne !

Négatif :
NON prédicat vaut vrai => WHERE ne rtient pas la ligne
NON prédicat vaut faux => WHERE retient la ligne
NON prédicat vaut INCONNU => WHERE ignore la ligne !

Ainsi la négation n'a aucun effet sur INCONNU, alors qu'elle inverse les valeurs VRAI et FAUX

Si vous avez pas compris cela vous êtes passé à côté de beaucoup de chose !...

A +

[Artemus24]

Salut SQLPRO.

Je reprends la phrase de mon dernier message que voici :

Autant ignorer la ligne lorsque le marqueur est à NULL quand on fait un test de valeur : "WHERE colonne = {valeur}".

et je la compare à la votre :

prédicat vaut INCONNU => WHERE ignore la ligne !

ou encore :

NON prédicat vaut INCONNU => WHERE ignore la ligne !

et franchement, je ne voie aucune différence entre ma proposition et la votre.
Ou alors nous n'avons pas la même définition du mot "ignorer".

Ce n'est pas la première fois que je constate ça, mais est-ce que vous me comprenez ma prose ?

@+