Utiliser une clause WHERE avant un INNER JOIN

Hello
Je souhaite realiser une jointure dans mes requetes sql. Le probleme, c'est que je dois utiliser une clause WHERE avant un INNER JOIN et que MySQL me renvoi toujours une erreur de syntaxe.
Exemple :
- 2 tables => admin & admin_secure
- chaque table a un champ id pour clef primaire (jusqu'a la c'est courant)

Ma requete : SELECT id, pass FROM admin WHERE id = 1 INNER JOIN admin_secure ON admin.id = admin_secure
Je sais que ma requete ne veut pas dire grand chose, on dira que je n'ai pas trop le choix en fait (long a expliquer). Je suis oblige d'utilsier ce type de requete et c'est la premiere fois que j'utilise les jointures en sql.... j'aimerais recuperer le contenu de admin_secure mais je ne peut pas faire d'union

Si quelqu'un pouvait m'aider, sa serait top

Merci

Salut,

Personnellement, j'ai jamais vraiment compris les différences entre les types de jointure SQL. Par exemple, la doc MySQL me dit :

join_table:
table_reference [INNER | CROSS] JOIN table_factor [join_condition]
  | table_reference STRAIGHT_JOIN table_factor
  | table_reference STRAIGHT_JOIN table_factor ON condition
  | table_reference LEFT [OUTER] JOIN table_referencejoin_condition
  | table_reference NATURAL [LEFT [OUTER]] JOIN table_factor
  | table_reference RIGHT [OUTER] JOIN table_referencejoin_condition
  | table_reference NATURAL [RIGHT [OUTER]] JOIN table_factor

Beuh....


Partant de là, j'utilise toujours le left join qui correspond (dans mon esprit) à "si tu trouve, mets le resultat, sinon, laisse vide".


Mais dans ton cas, l'erreur est la structure de ta requête (toujours la doc MySQL) :

SELECT
    [ALL | DISTINCT | DISTINCTROW ]
      [HIGH_PRIORITY]
      [STRAIGHT_JOIN]
      [SQL_SMALL_RESULT] [SQL_BIG_RESULT] [SQL_BUFFER_RESULT]
      [SQL_CACHE | SQL_NO_CACHE] [SQL_CALC_FOUND_ROWS]
select_expr, ...
[FROM table_references
[WHERE where_condition]
    [GROUP BY {col_name | expr | position}
      [ASC | DESC], ... [WITH ROLLUP]]
    [HAVING where_condition]
    [ORDER BY {col_name | expr | position}
      [ASC | DESC], ...]
    [LIMIT {[offset,] row_count | row_count OFFSET offset}]
    [PROCEDURE procedure_name(argument_list)]
    [INTO OUTFILE 'file_name' export_options
      | INTO DUMPFILE 'file_name'
      | INTO var_name [, var_name]]
    [FOR UPDATE | LOCK IN SHARE MODE]]

Tout en sachant que (trois lignes plus loin) :
table_references indicates the table or tables from which to retrieve rows. Its syntax is described in Section 13.2.7.1, "JOIN Syntax".


Or join syntaxe :

table_references:
table_reference [, table_reference] ...

table_reference:
table_factor
  | join_table

Nous voyons donc que les jointure arrivents EN MÊME TEMPS que la décalartion des tables ( et non après le WHERE )


Bref, as-tu pensé à faire une sous-requète ?

SELECT * FROM t1 WHERE column1 = (SELECT column1 FROM t2);
SELECT s1 FROM t1 WHERE s1 = ANY (SELECT s1 FROM t2);
SELECT s1 FROM t1 WHERE s1 IN    (SELECT s1 FROM t2);
...

Bonne chance, et n'oubli pas de lire le manuel...

"Personnellement, j'ai jamais vraiment compris les différences entre les types de jointure SQL."
Naturelles, équi, non-équi, autos, externes, hétérogènes, croisés et unions... ca en fait un bon paquet :p

http://sql.developpez.com/sqlaz/jointures/

A ben merci FhX,

Avec ça je suis comblé...

Ca m'a permit de revivre mes vieux cours de SQL : "La jointure croisée n'est autre que le produit cartésien de deux tables. Rappelons que le produit cartésien de deux ensembles n'est autre que la multiplication généralisée." Pardon !!! Qu'est-ce-qui dit là le monsieur ??? C'est à moi qui parle? Faut que je note ce truc, ça doit raporter un max de points au partiel...

Ca m'a aussi fait découvrir l'opérateur BETWEEN. Et pis finalement, tout le reste je le savais (Le cross join n'est qu'une perte de temps à écrire, le mot outer est fourni en option, left ou right join j'utilise déjà et le full join, ben c'est union...)


Par contre, Jean84, ces remarques sont pour toi :

• Les jointures faites dans la clause WHERE (ancienne syntaxe de 1986 !) ne permettent pas de faire la distinction de prime abord entre ce qui relève du filtrage et ce qui relève de la jointure.
• Il est à priori absurde de vouloir filtrer dans le WHERE (ce qui restreint les données du résultat) et de voiloir "élargir" ce résultat par une jointure dans la même clause WHERE de filtrage.
• La lisibilité des requêtes est plus grande en utilisant la syntaxe à base de JOIN, en isolant ce qui est du filtrage et de la jointure, mais aussi en isolant avec clarté chaque condition de jointures entre chaque couples de table.
• L'optimisation d'exécution de la requête est souvent plus pointue du fait de l'utilisation du JOIN.
• Lorsque l'on utilise l'ancienne syntaxe et que l'on supprime la clause WHERE a des fins de tests, le moteur SQL réalise le produit cartésiens des tables ce qui revient la plupart du temps à mettre à genoux le serveur !

A+

Ah oui, si... NATURAL, je ne connaissais pas

Et STRAIGHT, c'est quoi ?

Le straight permet l'utilisation spécifique d'un ordre de table.

En effet, lors d'une relation, mysql vérifie quel est le coté de la relation la plus favorable et utilise la table favorisée en première.
Lors d'un straight join, les tables sont dans l'ordre spécifié lors de l'écriture de la requète.

cf la doc :
L'ordre de lecture de tables forcé par LEFT JOIN et STRAIGHT JOIN aidera l'optimiseur de jointures (qui calcule l'ordre dans lequel les tables doivent être jointes) à faire son travail plus rapidement, puisqu'il y aura moins de permutations de tables à vérifier.

"Pardon !!! Qu'est-ce-qui dit là le monsieur ??? C'est à moi qui parle? Faut que je note ce truc, ça doit raporter un max de points au partiel..."
C'est la base de SQL :D
Quand même !!! :p :p

"Qu'est-ce-qui dit là le monsieur ???"

Et pourquoi ca pourrait pas être une dame pour une fois ?
Tu crois que ce sont des billes en SQL ? :o









Ouais si la plupart sont blondes.... ^^

Et ben merci chef !

Ok merci pour vos conseils, je vais voir ce que je peut faire.

Merci a vous deux