Discussion :

[projetM]

Salut,
En faisant des requetes sql je rencontre à chaque fois le meme probleme et je commet toujours la meme faute.
mon problème est avec EXISTS. toujours je fait la requete en utilisant des jointures et après avoir vu la correction je tien compte qu'elle se fait avec EXISTS.
Je sais pas s'il y a des personnes qui ont recontré ce probleme. Mais je pense que j'ai pas bien assimilé le role de EXISTS.

Merci d'avance.

[Ora92_IDS]

Vous pouvez nous donner un exemple de requete sur laquelle tu utilise exists

[SheikYerbouti]

EXISTS retourne un booléen indiquant si la clause select contenue entre les parenthèses est vrai ou fausse. ce n'est pas compliqué

Code :

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

1
2
3
Select 1 from dual 
where exists ( select col from the_table where id > 10 )
;

si le sous-select ramène au moins une ligne, exists retourne TRUE sinon il reourne FALSE.

[Magnus]

http://sql.developpez.com/sqlaz/sousrequetes/#L1.5.1

[nuke_y]

remi4444 je t'invoque !

[fsmrel]

Bonsoir ProjetM,

Supposons que nous voulions exprimer en SQL la question :

"Quels développeurs connaissent Oracle ?"

On peut écrire :

Code :

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

1
2
3
4
5
 
SELECT   D.Nom
FROM     Developpeur D, SGBD S 
WHERE    D.SGBD_Id = S.SGBD_Id
   AND   S.Nom = ‘Oracle’ ;

ou de façon équivalente :

Code :

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

1
2
3
4
5
6
7
8
9
 
SELECT D.Nom
FROM   Developpeur D
WHERE EXISTS 
           (SELECT  * 
            FROM    SGBD S
            WHERE   D.SGBD_Id = S.SGBD_Id
               AND  S.Nom = ‘Oracle’ 
           );

C'est-à-dire que les deux instructions fon double emploi et EXISTS pourrait disparaître du langage. Mais, là où il devient intéressant c'est au niveau de la négation :

"Quels développeurs ne connaissent pas Oracle ?"

Code :

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

1
2
3
4
5
6
7
8
9
 
SELECT D.Nom
FROM   Developpeur D
WHERE NOT EXISTS 
           (SELECT  * 
            FROM    SGBD S
            WHERE   D.SGBD_Id = S.SGBD_Id
               AND  S.Nom = ‘Oracle’ 
           );

SQL étant redondant, il y a de nombreuses autres façons de poser les questions...

[nuke_y]

Sauf que dans un cas comme celui-là (multiples lignes de SGDB pour 1 ligne de Developpeur) :

Code :

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

1
2
3
4
SELECT   D.Nom
FROM     Developpeur D, SGBD S 
WHERE    D.Dev_Id = S.Dev_Id
   AND   S.Nom = ‘Oracle’ ;

S'il existe plusieurs lignes dans SGBD pour un Nom "Oracle" (par exemple si on rajoute un champ Version qui contient "8i", "9i", etc.), tu vas ramener 2 fois les noms des développeurs et il faudra gérer avec un DISTINCT pour se débarasser des doublons.

Le EXISTS permet de s'affranchir de ce problème.

[remi4444]

C'est bien, à force de prendre la tete à tout le monde avec EXISTS, je vois que ça porte ses fruits...

Exemple:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
 
MAMAN
 
ID	PRENOM  	NOM
--	---------	----
1	Huguette 	Dugenou
2	Benedicte 	Martin
3	Veronique 	Durand
 
 
ENFANT  
 
ID	PRENOM		SEXE	MAM_ID
------	---------	-----	----
1	Marie		F	1
2	Paul		M	1
3	pierre		M	1
4	julie		F	2
5	chloe		F	2
6	Julien		M	3
7	Nicolas		M	3
 
 
Rechercher les mamans qui ont au moins une fille: 
 
select * from MAMAN 
 where exists
  ( select 1 from ENFANT 
      where MAMAN.ID = ENFANT.MAM_ID
        and ENFANT.SEXE = 'F' )

Sur le principe, il faut utiliser exists quand on ne ramène les lignes que d'une seule table et que les autres tables ne servent que de filtre. C'est plus optimisé qu'une jointure car oracle s'arrete à la première occurence trouvée. D'autre part, c'est plus adapté au besoin car il n'y a aucun risque de doublon.

Cadeau bonus: Par ailleurs, si on fait une vue avec la même requête, cette vue sera modifiable, ce qui est quand meme sympa pour de développement...

[nuke_y]

Invocation réussie

[remi4444]

Invocation réussie

Oui j'ai découvert cet appel un peu tard mais je suis venu quand meme

[fsmrel]

Sauf que dans un cas comme celui-là (multiples lignes de SGDB pour 1 ligne de Developpeur) :

Code :

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

1
2
3
4
5
 
SELECT   D.Nom
FROM     Developpeur D, SGBD S 
WHERE    D.Dev_Id = S.Dev_Id
   AND   S.Nom = ‘Oracle’ ;

S'il existe plusieurs lignes dans SGBD pour un Nom "Oracle" (par exemple si on rajoute un champ Version qui contient "8i", "9i", etc.), tu vas ramener 2 fois les noms des développeurs et il faudra gérer avec un DISTINCT pour se débarasser des doublons.

Le EXISTS permet de s'affranchir de ce problème.

C’est on ne peut plus vrai : SQL produit malheureusement des doublons (nom du développeur dans l’exemple), d’où la nécessité d’utiliser la clause DISTINCT pour obtenir une équivalence entre l’utilisation d’une jointure et celle d’un EXISTS. SQL n’en reste pas moins redondant et bavard. La possibilité de produire des doublons renforce le verdict des théoriciens du Relationnel (feu E.F. Codd père du Modèle relationnel et ses successeurs C.J. Date, H. Darwen, D. McGoveran, etc.), comme quoi SQL (Sorry Query Language) n’est pas relationnel, puisqu’il autorise la manipulation de sacs à tuples (tuple bags) alors que le Modèle relationnel l’interdit (par définition les doublons sont autorisés dans un sac et interdits pour une table qui est une spécialisation du sac). Si SQL était relationnel, de lui-même il éliminerait les doublons du résultat (qui doit être une table en vertu de la propriété de fermeture, selon laquelle le résultat d’une opération relationnelle est de même nature que les opérandes en entrée, c’est-à-dire une table). Les verrues ad-hoc du genre DISTINCT n’auraient plus lieu de polluer le langage et compliquer la vie des développeurs.

[nuke_y]

J'aurai du mal à te suivre dans ce débat sur la théorie du SQL mais si les développeurs veulent coder proprement ils peuvent (par exemple en utilisant le EXISTS).

[remi4444]

SQL n'est qu'une syntaxe, il n'a pas a être "relationnel" ou pas, c'est le modèle qui l'est ou pas...

Mais bien souvent on utilise mal cette syntaxe. En fait, il n'y a pas de doublon généré par la jointure, c'est simplement le fait qu'on affiche pas toute les colonnes qui donne cette illusion. Il faut d'abord bien se formuler la question. dans mon exemple j'ai demandé: "TOUTES LES MAMANS AYANT AU MOINS UNE FILLE", la traduction pour ça est le EXISTS, point.

J'aurais pu demander "TOUTES LES CORRESPONDANCES ENFANT-MAMAN DONT L'ENFANT EST UNE FILLE", à ce moment là il faut utiliser une jointure, mais c'est normal puisque je veux afficher des données sur les 2 tables.

La syntaxe aurait été:

Code :

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

1
2
3
SELECT MAMAN.*,ENFANT.* FROM MAMAN,ENFANT 
   WHERE MAMAN.ID = ENFANT.MAM_ID
        AND ENFANT.SEXE = 'F'

Et le resultat sera l'ensemble des correspondances:

Code :

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

1
2
3
4
5
ID	PRENOM  	NOM	ID	PRENOM		SEXE	MAM_ID
--	---------	----	------	---------	-----	----
1	Huguette 	Dugenou	1	Marie		F	1
2	Benedicte 	Martin	4	julie		F	2
2	Benedicte 	Martin	5	chloe		F	2

Il se trouve que "Benedicte martin" apparait 2 fois puisqu'elle a 2 filles, mais il n'y a aucune ligne identique à une autre.

Simplement que se passe-t-il si je n'affiche que les colonnes de la table MAMAN:

Code :

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

1
2
3
4
5
6
7
8
9
SELECT MAMAN.* FROM MAMAN,ENFANT 
   WHERE MAMAN.ID = ENFANT.MAM_ID
        AND ENFANT.SEXE = 'F' 
 
ID	PRENOM  	NOM	
--	---------	----	------	
1	Huguette 	Dugenou	
2	Benedicte 	Martin	
2	Benedicte 	Martin

J'ai demandé toutes les correspondances MAMAN-FILLE mais je n'ai pas affiché toutes les colonnes, ça n'empêche que Benedicte Martin a toujours 2 filles, donc elle apparait toujours 2 fois, cette double apparition a donc une signification, ça reste conforme à mon modèle relationnel. Sauf qu'il est un peu loufoque de demander toutes les correspondances d'une relation et de n'afficher q'un seul coté de la relation

Si vous ne comprenez pas pourquoi votre requête ramène des "doublons", affichez toutes les colonnes de toutes les tables jointes et vous comprendrez

[fsmrel]

Simplement que se passe-t-il si je n'affiche que les colonnes de la table MAMAN:

Code :

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

1
2
3
4
5
6
7
8
9
10
 
SELECT MAMAN.* FROM MAMAN,ENFANT 
   WHERE MAMAN.ID = ENFANT.MAM_ID
        AND ENFANT.SEXE = 'F' 
 
ID	PRENOM  	NOM	
--	---------	----	------	
1	Huguette 	Dugenou	
2	Benedicte 	Martin	
2	Benedicte 	Martin

J'ai demandé toutes les correspondances MAMAN-FILLE mais je n'ai pas affiché toutes les colonnes, ça n'empêche que Benedicte Martin a toujours 2 filles, donc elle apparait toujours 2 fois, cette double apparition a donc une signification, ça reste conforme à mon modèle relationnel. Sauf qu'il est un peu loufoque de demander toutes les correspondances d'une relation et de n'afficher q'un seul coté de la relation

On détecte la présence d’un doublon <2, "Benedicte", "Martin">, le résultat n’est donc pas une table mais un sac. Vous ne pouvez plus vous en servir comme opérande en entrée (l’emboîter comme expression de table dans un FROM par exemple) sans risquer de faire dérailler les opérateurs relationnels qui ne fonctionnent qu’avec des tables authentiques (relations au sens de ce qu’on appelle LE Modèle Relationnel, inventé en 1970 par Ted Codd).

SQL n'est qu'une syntaxe, il n'a pas a être "relationnel" ou pas, c'est le modèle qui l'est ou pas

SQL n’est peut-être qu’une syntaxe, mais ses inventeurs (Chamberlin et al.) ont quand même voulu qu’il soit conforme au Modèle Relationnel de Codd, c’est-à-dire qu’il soit un langage fait pour manipuler des ensembles (ce que sont les tables). Or, les ensembles ne comportent pas de doublons : un deux, trois, etc. n’existent qu’en un seul exemplaire dans l’ensemble N des entiers naturels (sinon gare au comportement de l'arithmétique)... Les sacs ne sont pas des ensembles et les utiliser avec des opérateurs relationnels, c’est manipuler de la dynamite et à tout le moins se priver de la fiabilité mathématique inhérente à l’algèbre relationnelle, pour finalement produire du n’importe quoi (de plus en plus vite au fil des versions des SGBD, bien sûr).

[nuke_y]

Je dirais que tu as sûrement raison fsmrel, mais entre les théories mathématiques et leurs applications, il y a souvent une grande différence.

Je suis sûr que les évolutions apportées au SQL (et les fonctions spécifiques implémentées par les différents SGBD) éloignent petit à petit la réalité pratique des BDD et du SQL de la théorie mathématique parfaite mais comme dit le proverbe :

Dans l'eau trop pure ne nage aucun poisson

et pour bosser mieux vaut un système imparfait utilisable, qu'un système parfait inutilisable.

Je citerai pour exemple le fait que rémi peut défendre très simplement son point de vue sur un cas concret, alors que personnellement je n'ai rien compris à ton explication de sac (qui est sûrement tout à fait juste).

[remi4444]

On détecte la présence d’un doublon <2, "Benedicte", "Martin">, le résultat n’est donc pas une table mais un sac.

et alors ??

Si on veut etre sûr de ne pas avoir des doublons, il faut afficher les identifiants de chaque table dans le select, mais libre à chacun de le faire ou pas... les informaticiennes et informaticiens sont des grandes filles et des grands garçons, ils ont un outils souple et puissant entre les mains, libres à eux de l'utiliser de façons pure et mathématiques ou de l'adapter rapidement aux problèmes pratiques auquels ils sont confrontés...

... Or, les ensembles ne comportent pas de doublons : un deux, trois, etc. n’existent qu’en un seul exemplaire dans l’ensemble N des entiers naturels (sinon gare au comportement de l'arithmétique)...

Mais le fait que "benedicte martin" apparaisse 2 fois est une information en soit puisqu'elle apparait autant de fois qu'elle a de filles, encore heureux que le langage sql ne me l'interdise pas! imaginons que ce soit une requête pour imprimer des tickets de cantine, c'est quand meme normal qu'il y en ait 2 pour elle...

[nuke_y]

ce qu'il veut dire, je pense, c'est qu'au lieu de :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
SELECT MAMAN.* FROM MAMAN,ENFANT 
   WHERE MAMAN.ID = ENFANT.MAM_ID
        AND ENFANT.SEXE = 'F' 
 
ID	PRENOM  	NOM	
--	---------	----	------	
1	Huguette 	Dugenou	
2	Benedicte 	Martin	
2	Benedicte 	Martin

Il faudrait que dans chaque colonne n'apparaisse aucun doublon, car il s'agit de valeurs d'un ensemble (donc de valeurs FORCEMENT distinctes).

En gros ça voudrait dire que ta requête devrait fonctionner ainsi :

Code :

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

1
2
3
4
5
6
7
8
9
 
SELECT MAMAN.ID FROM MAMAN,ENFANT 
   WHERE MAMAN.ID = ENFANT.MAM_ID
        AND ENFANT.SEXE = 'F' 
 
ID
--
1
2

Code :

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

1
2
3
4
5
6
7
8
9
 
SELECT MAMAN.ID, MAMAN.PRENOM FROM MAMAN,ENFANT 
   WHERE MAMAN.ID = ENFANT.MAM_ID
        AND ENFANT.SEXE = 'F' 
 
ID	PRENOM
--	---------
1	Huguette
2	Benedicte

Code :

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

1
2
3
4
5
6
7
8
 
SELECT MAMAN.*,ENFANT.* FROM MAMAN,ENFANT WHERE MAMAN.ID = ENFANT.MAM_ID AND ENFANT.SEXE = 'F'
 
ID	PRENOM  	NOM	ID	PRENOM		SEXE	MAM_ID
--	---------	----	------	---------	-----	----
1	Huguette 	Dugenou	1	Marie		F	1
2	Benedicte 	Martin	4	julie		F	2
2	Benedicte 	Martin	5	chloe		F	2

Et encore, dans le dernier exemple, je me demande même s'il ne devrait pas apparaître seulement les valeurs distinctes. Mais dans ce cas, comment faire pour travailler "en ligne" ?

Je pense que vraiment la réalité des SGDB et du SQL s'est éloignée de la théorie mathématique parce qu'on avait besoin d'un système plus pratique que théorique.

Mais rien ne dit qu'on ne verra pas apparaître dans quelques années de nouveaux SGBD plus proches de la théorie mathématique et qui offriront un développement plus efficace dans certains cas.

[remi4444]

oui, ça voudrait dire que le DISTINCT serait obligatoire, ou plutot qu'une requête dont on ne ramène des colonnes que d'une seule table soit automatiquement réécrite avec des EXISTS. Mais je vois pas en quoi ce serait mieux puisque tout existe déja.
Si on veut faire du filtrage, on utilise EXISTS, si on veux l'exaustivité des correspondances, on utilise une jointure... on peut critiquer la syntaxe, trouver que la syntaxe actuelle de la jointure devrait plutot engendrer un filtrage mais là on s'en sort plus... si j'ai envie de faire des doublons apres tout, pourquoi une syntaxe m'en empecherait ?

[remi4444]

Je pense que vraiment la réalité des SGDB et du SQL s'est éloignée de la théorie mathématique parce qu'on avait besoin d'un système plus pratique que théorique.

Si la pratique s'est éloignée des mathématiques, c'est que les mathématiques sont en retard... mais je ne crois pas que ce soit vrai, on peut avoir l'impression que la pratique s'est éloignée des leçons de math qu'on a apprises plus jeune ce qui n'est pas tout à fait la meme chose (à moins de prétendre avoir TOUT appris en math... ) Les math servent à simplifier les choses, à poser des principes pour faciliter la vie aux autres disciplines dont l'informatique. S'interdire de resoudre un problème sous prétexte qu'on ne trouve pas de théorie pure est pour moi une abhération...

[fsmrel]

ça voudrait dire que le DISTINCT serait obligatoire, ou plutôt qu'une requête dont on ne ramène des colonnes que d'une seule table soit automatiquement réécrite avec des EXISTS. Mais je vois pas en quoi ce serait mieux puisque tout existe déjà.

Essayez de comprendre. J'ai écrit que l'on doit pouvoir écrire :

Code :

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

1
2
3
4
5
 
SELECT   D.Nom
FROM     Developpeur D, SGBD S 
WHERE    D.Dev_Id = S.Dev_Id
   AND   S.Nom = ‘Oracle’ ;

sans récupérer des doublons, sans avoir à rajouter un DISTINCT ou autre artifice et qu'il est à la charge du langage et non pas à votre charge d'éliminer les doublons : le but est que le comportement du SGBD reste prévisible, stable et que ce ne soit pas à vous de pallier les lacunes de SQL. C’est le B-A BA de l’algèbre relationnelle que vous utilisez. Si SQL avait été conçu correctement dès le départ, vous n’y verriez aujourd’hui aucun inconvénient, au contraire...

ce qu'il veut dire, je pense, c'est qu'au lieu de :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
SELECT MAMAN.* FROM MAMAN,ENFANT 
   WHERE MAMAN.ID = ENFANT.MAM_ID
        AND ENFANT.SEXE = 'F' 
 
ID	PRENOM  	NOM	
--	---------	----	------	
1	Huguette 	Dugenou	
2	Benedicte 	Martin	
2	Benedicte 	Martin

Il faudrait que dans chaque colonne n'apparaisse aucun doublon, car il s'agit de valeurs d'un ensemble (donc de valeurs FORCEMENT distinctes).

Ceci est une variante de ce qui précède. Je répète donc que c'est à SQL de produire une table plutôt d’un sac de doublons, sans que nous ayons besoin de perdre du temps à chercher des astuces.

On détecte la présence d’un doublon <2, "Benedicte", "Martin">, le résultat n’est donc pas une table mais un sac.

et alors ??
Si on veut etre sûr de ne pas avoir des doublons, il faut afficher les identifiants de chaque table dans le select, mais libre à chacun de le faire ou pas... les informaticiennes et informaticiens sont des grandes filles et des grands garçons, ils ont un outils souple et puissant entre les mains, libres à eux de l'utiliser de façons pure et mathématiques ou de l'adapter rapidement aux problèmes pratiques auquels ils sont confrontés...

Je répète encore que c'est à SQL d'éliminer les doublons, cf. ci-dessus.
Maintenant, j'étais informaticien quand vous n'étiez pas nés, quand l'informatique ne s'enseignait pas encore à l'université et que l'on avait que des cartes perforées et des bandes magnétiques (même pas de disques, ni d’écrans) et qu’on développait en assembleur. Des informaticiennes et des informaticiens, j'en ai formé, piloté, consolé et morigéné des régiments, à tous les niveaux et de toutes origines, ingénieurs système, DBA, concepteurs, développeurs, chefs de projets... Ils ont un outil pas très souple mais puissant, mais je rappelle aussi que l'on ne s’improvise pas artificier et que la dynamite, quand ça pète, ça pète et que l'on a souvent appelé Fsmrel au secours avant que n’éclate de drame. Parfois après.

J'ai personnellement développé des tombereaux de requêtes SQL pendant plus de 20 ans, j'ai été au secours de bases de données à l'agonie pour les faire revivre, 50 heures d'affilée en salle machine, sandwich en main, sans connaître les bases en question (ou les avoir lâchées pendant un an ou deux), pour que les traitements se terminent dans les temps et pas au bout de 10 jours. Pour récupérer dans les logs des centaines de milliers de lignes orphelines (clés étrangères sans clés primaires en face), j’en passe et des meilleures. Le pragmatisme je connais, j’ai donné et c’est pour ça que j’insiste pour une remontée vers des bases de données saines. J'ai modélisé, expertisé, enseigné, audité, j'ai engagé mon entreprise sur la performance des applications, dans les plus grandes entreprises françaises, dans le monde de la banque, de l’assurance, de l’industrie, des services, de la retraite, chez les militaires et les marins... J'ai aussi théorisé, travaillé en collaboration avec les universitaires, donné des conférences en relation avec des gens de tous pays. Aujourd’hui, je souhaite surtout qu’une bonne fée se penche sur le Monstre (qui a quand même un bon fond) pour le transformer avec sa baguette magique en prince charmant, même si ça ne fait pas plaisir à Gargamel.

Mais rien ne dit qu'on ne verra pas apparaître dans quelques années de nouveaux SGBD plus proches de la théorie mathématique et qui offriront un développement plus efficace dans certains cas.

De tels SGBD ont existé, mais ils ont été tués par le Monstre (par exemple PRTV, The Peterlee Relational Test Vehicle, fouillez sur la Toile), cf. ci-dessus. Je vous conseille aussi de découvrir Tutorial D.

Mais le fait que "benedicte martin" apparaisse 2 fois est une information en soit puisqu'elle apparait autant de fois qu'elle a de filles

C'est vous qui savez que c’est à cause de ses filles, mais le résultat n’en dit rien, il ne fournit aucune information, sinon qu’il redonde, ce qui n’est pas pour rassurer. Si donc vous emboîtez cela dans une autre requête : unpredictable result.

Je dirais que tu as sûrement raison fsmrel, mais entre les théories mathématiques et leurs applications, il y a souvent une grande différence.

Don't worry, ça fait 20 ans que je suis au courant et, dans le cas de SQL je trouve que cette différence est excessive. Cela dit, une fois que les marchands tels Larry Ellison et Gargamel ont mis le grappin dessus, ça a été foutu. La preuve. Le grand schtroumpf a peut-être quand même quelque chose en réserve ?

et pour bosser mieux vaut un système imparfait utilisable, qu'un système parfait inutilisable.

Certes, mais, comme je l’ai dit, SQL est trop imparfait et le système idéal ne peut qu’être exploitable, car il ne peut être une usine à gaz. Le problème, pour s'en rendre compte est qu'il faut au moins un an d'étude de Tutorial D avant de virer sa cuti, se rendre compte qu'il existe au moins un système conforme à la théorie. Je rappelle que PRTV était près de l’idéal. En tout cas, ne comptons pas sur les marchands et Gargamel pour améliorer les choses.

personnellement je n'ai rien compris à ton explication de sac

Je recommence. Un sac est comme une table sans clé primaire où l'on doublonne à tout va et où les opérateurs relationnels les fonctions d'agrégation seront mises à mal. Je rappelle que l'ensemble N des nombres naturels serait un sac si Un ou Deux ou Trois, etc. pouvaient doublonner selon notre bon plaisir. Adieu l'arithmétique, Rollback vers la préhistoire...

Dans l'eau trop pure ne nage aucun poisson

Dans une eau bien polluée, ça n’est pas mieux...