recherche dans les tables

**emialpina** · 07/12/2012, 00h03

Bonjour à toutes et à tous

Que je vous explique mon problème. J’ai 2 tables.
Une "eleves"
Id, nom, prenom, age, taille, tel, email, ville, loisirs

l’autre "eleves_recherche"
Id, nom, prenom, age, taille, tel, email, ville, loisirs

Le champ "loisirs" peut prendre plusieurs valeurs séparées par un point virgule. (lecture;natation;vélo)
Je veux tout simplement rechercher des résultats dans la table "eleves" avec les critères de la table "eleves_recherche", en sachant que on a plusieurs lignes dans les 2 tables, et que pour les loisirs un qui correspond est suffisant

Code :

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

1
2
3
4
SELECT * 
FROM eleves, eleves_recherche  
where eleves_recherche.age <= eleves.age 
    and eleves_recherche.loisirs in (eleves.loisirs)

Ma requête ne fonctionne pas, car on ne peut pas mettre la condition in comme ça, mais je ne sais pas comment la faire

Je vous remercie de bien vouloir m'aider

**CinePhil** · 07/12/2012, 09h07

1) Pourquoi avoir deux tables avec la même structure ?

2) Votre modèle de données n'est pas normalisé !

Le champ "loisirs" peut prendre plusieurs valeurs séparées par un point virgule. (lecture;natation;vélo)

Ceci contrevient à la première forme normale !

Vous avez donc la règle de gestion suivante :
Un élève peut pratiquer plusieurs loisirs et un loisir peut être pratiqué par plusieurs élèves.

Cette règle de gestion entraîne le morceau de MCD suivant :
eleve -0,n----pratiquer----0,n- loisir

Et ce MCD engendrera la création des tables suivantes :
te_eleve_elv (elv_id, elv_nom...)
te_loisir_lsr (lsr_id, lsr_nom...)
tj_elv_pratiquer_lsr_epl (epl_id_eleve, epl_id_loisir...)

Profitez-en aussi pour externaliser la ville afin de ne pas avoir plusieurs fois la même ville avec des orthographes différentes...

Un élève habite dans une seule ville et une ville peut héberger plusieurs élèves.

eleve -1,1----habiter----0,n- ville

tr_ville_vil (vil_id, vil_nom...)
te_eleve_elv (elv_id, elv_id_ville, elv_nom...)

3) Les jointures s'écrivent depuis 20 ans avec l'opérateur JOIN ; il serait temps de s'y mettre !

4) Il vaut mieux éviter la guerre des étoiles !

5)

Je veux tout simplement rechercher des résultats dans la table "eleves" avec les critères de la table "eleves_recherche"

D'après votre requête, vous faites une non équi-jointure sur l'âge des élèves, ce qui est très bizarre comme condition de jointure !

Votre requête va associer, pour chaque élève de la table eleves_recherche, tous ceux de la table eleves qui ont un âge supérieur ou égal !

6) Nommez vos entités types au singulier car elles sont issues des règles de gestion qui décrivent ce qui se passe successivement pour 1 instance de chaque entité type.
Voir les exemples que j'ai donnés plus haut.

7) Les champs sont à la campagne ou dans les formulaires, pas dans les tables SQL qui ne sont composées que de colonnes et de lignes.

Expliquez mieux votre besoin. J'ai l'impression que vous avez mélangé le modèle de données et le processus de recherche des données dans la BDD.

Vous avez un gros besoin d'approfondir vos connaissances sur ce qu'est une base de données relationnelle et comment on s'en sert. N'hésitez pas à passer du temps sur le site de SQLPro.

**emialpina** · 07/12/2012, 14h11

Merci pour votre réponse.
Il y a 2 tables car je veux que sa fonctionne un peu comme sur les réseaux sociaux. La table "eleves" représente les eleves inscrits sur le site.
La table "eleves_recherche" est remplit par les élevés qui recherche un copain avec certaines critères, mais qui n'est pas encore dans la base. Au moment quand il y aura un il recevra un mail automatique. Entre temps les données de sa recherche sont stockées dans la table "eleves_recherche".
Pour le champ loisirs il peut cocher plusieurs cases qui corresponds chacune à un loisir. C'est pour cela que je me retrouve coincé, et je cherche la solution pour débloquer rapidement.
Merci beaucoup

**CinePhil** · 07/12/2012, 15h08

Et bien comme je te l'ai dit, comme ton modèle de données est mauvais, tu te retrouves coincé pour faire une requête qui serait simple avec un modèle normalisé.

Modifie ton modèle de données comme je l'ai indiqué car là tu vas droit dans le mur avec tes deux tables telles qu'elles sont faites !

**emialpina** · 08/12/2012, 05h14

Vous appelez quoi modèle normalisé?

**CinePhil** · 08/12/2012, 08h18

Je te renvoie vers la bible de fsmrel mais contente toi des têtes de chapitre et petites explications simples en parcurant le document parce que l'ensemble est plutôt complexe et demande du temps que je n'ai moi-même jamais pris pour absorber cette somme.

Voici par exemple la première définition de la 1ère forme normale et qui est assez simple à comprendre (chapitre 2.2 dans l'article référencé ci-dessus) :

« Une relation est en première forme normale si aucun de ses domaines ne peut contenir des éléments qui soient eux-mêmes des ensembles. Une relation qui n'est pas en première forme normale est dite non normalisée. »

Dans ton cas, cela veut dire que la colonne "loisirs", qui devrait être nommée au singulier, ne peut contenir qu'un seule loisir par ligne de la table, ce qui impliquerait que chaque élève ne déclare qu'un seul loisir.
Comme apparemment un élève peut déclarer plusieurs loisirs, il faut modéliser les données comme je l'ai fait dans ma première réponse.

**fsmrel** · 08/12/2012, 16h29

Bonsoir,

Envoyé par CinePhil

Ceci contrevient à la première forme normale !

Je ne sais pas si le concept de première forme normale (1NF ou 1FN) dit grand-chose à emialpina... Quoi qu’il en soit, il y a la lettre d’une part et l’esprit d’autre part.

je rappelle que si l’attribut Loisirs est du type CHAR ou VARCHAR, la première forme normale est à la lettre respectée : elle serait violée si cet attribut était du type ARRAY (cf. PostgreSQL).

En revanche, cette malheureuse première forme normale est évidemment bafouée dans l’esprit et l’on ne peut qu’être d’accord avec la recommandation que vous faites à emialpina de mettre en œuvre le type d’entité PRATIQUER s’il veut s’en sortir.

Envoyé par CinePhil

Les jointures s'écrivent depuis 20 ans avec l'opérateur JOIN ; il serait temps de s'y mettre !

C’est un point de vue...
Disons que l’avantage qu’offre INNER JOIN par rapport à CROSS JOIN est celui de la lisibilité quand il y a plusieurs jointures.

Selon la norme, la clause FROM doit respecter la syntaxe :

FROM <Table reference> [, <Table reference> ...]

Où Table reference peut notamment représenter un simple nom de table.

Que l’on code

Code SQL :

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

1
2
SELECT item1, ... itemn
FROM   A INNER JOIN B ON A.attr1 = B.Attr2

Ou

Code SQL :

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

1
2
3
SELECT item1, ... itemn
FROM   A, B
WHERE  A.attr1 = B.Attr2

Alors un optimiseur digne de ce nom ramène ces requêtes à quelque chose de commun.

La bonne vieille expression antique et solennelle « A, B » a été baptisée CROSS JOIN par la norme SQL-92, mais cela ne change rien à l’affaire.

Je me réfère en cela à A Guide to THE SQL STANDARD Third Edition par C.J. Date et Hugh Darwen.

Pour mémoire, Darwen a longtemps représenté le Royaume-Uni au sein des comités qui font la norme (et fait remettre aux calendes la prise en compte de propositions qu'il a démontré comme étant invalides donc pour le moins dangereuses).

Nonobstant mes remarques, les recommandations que vous faites à emialpina méritent un grand

.

**CinePhil** · 08/12/2012, 18h23

Je me bats quotidiennement contre le non emploi de JOIN pour les jointures, ici et ailleurs.

Je ne compte plus le nombre de questions posées dans nos forums BDD que j'ai résoluées rien qu'en récrivant la requête avec JOIN ON en lieu et place de FROM WHERE.

Et je suis ces temps professionnels ci quotidiennenment confronté à des requêtes contenant un bon paquet de jointures et je passe un temps certain à les récrire pour les comprendre. Je dois même avouer que les dernières que j'ai examinées m'ont laissées dans le doute sur la bonne manière d'ordonner les JOIN à cause de boucles dans les conditions de jointures !

Bref, quand je vois des jointures à l'ancienne, je fais comme toi face au bonhomme NULL, je sors ma sulfateuse !

**fsmrel** · 10/12/2012, 03h10

Envoyé par CinePhil

Bref, quand je vois des jointures à l'ancienne, je fais comme toi face au bonhomme NULL, je sors ma sulfateuse !

Si en plus le NULL montre lui aussi le bout de son nez dans une requête, alors on pourra faire un tir groupé !

En tout cas, remerciez Chris Date d'avoir inventé la jointure moderne, laquelle a eu l'heur de séduire ceux qui font la norme SQL ! C'est l'occasion pour moi de rappeller ce que j'ai déjà écrit à ce sujet :

« On peut aller jusqu’à dire que l’utilisation de la paire (FROM, WHERE) pour exprimer la jointure peut être considérée comme obsolète depuis 25 ans. En effet, c’est dans son ouvrage Relational Databases, Selected Writings, paru en 1986 que C. J. Date écrivit (chapitre 16, Outer join) :

[...]We propose the introduction of an explicit JOIN operation into SQL —where the keyword JOIN refers specifically to the (inner or outer) natural join [...]

et il fournit la BNF qui va bien :

Code SQL :

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

1
2
3
4
join-expression 
   ::= [ OUTER | INNER ] JOIN relation-commalist on-clause
on-clause
    ::= ON ( attribute-commalist ) [ AS introduced-name ]

Dans Relational Databases, Writings 1989-1991, paru en 1992, C. J. Date écrivit par ailleurs (au chapitre 19, Watch Out for Outer join, initialement publié dans InfoDB 5, No. 1 (Spring/Summer 1990)) :

I am glad to see that the SQL standards committees are in fact planning such an extension in their proposed follow-on to the existing SQL standard known as SQL2.

Cela dit, les éditeurs de SGBD ont pris plus ou moins leur temps avant de proposer d’effectuer la jointure au niveau du seul FROM, sans que l’on ait à fournir la condition de jointure au sein du WHERE. Par exemple, IBM n’a proposé la construction INNER JOIN qu’en novembre 1995, avec la version 4 de DB2 for MVS/ESA (autant dire en 1998 pour nous, pauvres utilisateurs, toujours en retard d’une version, contexte de production, plans de tests, de régression, etc. obligent). A la décharge d’IBM, la V3 de DB2 avait été livrée en 1993, et il n’était évidemment pas possible de la chambouler, d’envoyer au pilon des wagons de documentation prêts depuis un an, tout cela parce que simultanément naquit SQL/2.

Quant à ORACLE... Si j’ai bien suivi les pointeurs (merci de me corriger si j’ai lu de travers), ça n’est qu’avec Oracle10g Release 2 que l’on a pu coder JOIN pour effectuer une jointure naturelle, c'est-à-dire en 2006. Là encore, avec une version de retard, les développeurs ont des excuses...

Quant à MySQL... Je suis incompétent pour répondre, mais vu sa date de naissance (1995 si j’en crois Wikipedia), il a probablement dû prendre en compte la norme dès le départ.

En ce qui concerne SQL Server, SQLpro sera sans doute à même de nous donner les informations correspondantes. »

Etc.

Bon, je vais aller me ravitailler en 12,7 mm (je travaille de préférence à la RIA de 50).