+ Répondre à la discussion
Affichage des résultats 1 à 11 sur 11
  1. #1
    Invité de passage
    Inscrit en
    mai 2012
    Messages
    8
    Détails du profil
    Informations forums :
    Inscription : mai 2012
    Messages : 8
    Points : 0
    Points
    0

    Par défaut recherche dans les tables

    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 :
    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

  2. #2
    Modérateur
    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    14 008
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 14 008
    Points : 25 265
    Points
    25 265

    Par défaut

    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.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale de Formation Agronomique. Autoentrepreneur.
    Mon blog sur la conception des BDD, le langage SQL, le PHP avec Zend Framework...
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  3. #3
    Invité de passage
    Inscrit en
    mai 2012
    Messages
    8
    Détails du profil
    Informations forums :
    Inscription : mai 2012
    Messages : 8
    Points : 0
    Points
    0

    Par défaut

    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

  4. #4
    Modérateur
    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    14 008
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 14 008
    Points : 25 265
    Points
    25 265

    Par défaut

    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 !
    Philippe Leménager. Ingénieur d'étude à l'École Nationale de Formation Agronomique. Autoentrepreneur.
    Mon blog sur la conception des BDD, le langage SQL, le PHP avec Zend Framework...
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  5. #5
    Invité de passage
    Inscrit en
    mai 2012
    Messages
    8
    Détails du profil
    Informations forums :
    Inscription : mai 2012
    Messages : 8
    Points : 0
    Points
    0

    Par défaut

    Vous appelez quoi modèle normalisé?

  6. #6
    Modérateur
    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    14 008
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 14 008
    Points : 25 265
    Points
    25 265

    Par défaut

    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.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale de Formation Agronomique. Autoentrepreneur.
    Mon blog sur la conception des BDD, le langage SQL, le PHP avec Zend Framework...
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  7. #7
    Expert Confirmé Sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    4 887
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Autre

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 4 887
    Points : 13 984
    Points
    13 984

    Par défaut

    Bonsoir,


    Citation Envoyé par CinePhil Voir le message
    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.


    Citation Envoyé par CinePhil Voir le message
    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> ...]
    Table reference peut notamment représenter un simple nom de table.

    Que l’on code

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

    Code SQL :
    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 .
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)


    De grâce, pas de questions techniques par MP, ma boîte de réception explose !
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale (Bonne lecture !)

  8. #8
    Modérateur
    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    14 008
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 14 008
    Points : 25 265
    Points
    25 265

    Par défaut

    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 !
    Philippe Leménager. Ingénieur d'étude à l'École Nationale de Formation Agronomique. Autoentrepreneur.
    Mon blog sur la conception des BDD, le langage SQL, le PHP avec Zend Framework...
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  9. #9
    Expert Confirmé Sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    4 887
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Autre

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 4 887
    Points : 13 984
    Points
    13 984

    Par défaut

    Citation Envoyé par CinePhil Voir le message
    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 :
    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).
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)


    De grâce, pas de questions techniques par MP, ma boîte de réception explose !
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale (Bonne lecture !)

  10. #10
    Invité de passage
    Inscrit en
    mai 2012
    Messages
    8
    Détails du profil
    Informations forums :
    Inscription : mai 2012
    Messages : 8
    Points : 0
    Points
    0

    Par défaut

    Je vous remercie de vos réponses.

    Je vous souhaite bonnes fêtes de fin d'année.

    A bientôt

  11. #11
    Expert Confirmé Sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    4 887
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Autre

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 4 887
    Points : 13 984
    Points
    13 984

    Par défaut

    Merci emialpina, et bonnes fêtes à vous aussi !
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)


    De grâce, pas de questions techniques par MP, ma boîte de réception explose !
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale (Bonne lecture !)

+ Répondre à la discussion
Cette discussion est résolue.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •