SELECT c.*, f.* FROM Contrat c INNER JOIN FactureClient f ON c.id_contrat = f.id_contrat WHERE c.destination = (paramètre php).
 
ou
 
SELECT c.*, f.* FROM Contrat c, FactureClient f WHERE c.id_contrat = f.id_contrat AND c.destination = (paramètre php).
 
En gros je ne peux pas faire les tests moi même pour une raison X mais il y a environ 15 000 entrées dans contrats et 10 000 dans factures, et environ 20 champs dans chaque table.
 
Le but est d'optimiser le temps d'execution de la requete.
Je cherche donc des petits moyens ( en particulier sur les jointures de tables, certaines fois il y a 5 jointures avec 10000 entrées en moyenne par table ) pour optimiser ces requetes.
 
 
Merci d'avance

La première est plus rapide... A condition de n'exécuter qu'une seule fois la requête, et le gain est de l'ordre de 0,00000000000001 % (temps de compilation)
 
Cependant, la première solution ouvre la perspective d'utilisation de certains aspects complexes du langage SQL, qui ne sont pas permis (ou limités) avec la seconde syntaxe.

Sinon il y aurait une solution pour des jointures avec des grosses tables comme celles ci pour optimiser le temps d'execution? Le plus souvent c'est un parcours des tables avec les id de la table 1 qui sont égaux aux id de la table 2 etc...
 
En fait ce que je veux savoir c'est comment traiter efficacement les jointures entre deux "grosses" tables.
 
Juste un petit apparté :  
 
SELECT ....... FROM table1 t1 INNER JOIN ( table2 t2 INNER JOIN (table3 t3 INNER JOIN table4 t4 ON t4.id = t3.id = 2 ) ON t2.id = t3.id ) ON t1.id = t2.id WHERE ......
 
Cela est t'il possible?

ON (T4.id=T3.id and T3.id=2) non?

Oui voila
Le reste c'est bon?

Je sais pas j'ai pas regardé en détail mais ça me semble correct.

oui oui, ce genre de requête est parfaitement possible.
 
pour "opitmiser" des jointures toutes bêtes comme ça, y'a pas 36 choses à faire :
1/ vérifier que les clés primaires existent bien sur les tables
2/ vérifier que les clés étrangères existent bien sur les relations
3/ vérifier que les clés étrangères tapent bien sur des clés primaires et non des clés alternatives (dans ce cas, même un index unique sur la clé étrangère en question, et non seulement une contrainte d'unicité)

Pour moi ces deux écritures sont rigoureusement identiques, je ne sais pas sur quel SGBD celà doit tourner, mais en tout cas sur Oracle le plan d'exécution sera exactement le même.
 

 
Je ne vois pas en quoi la deuxième écriture limite les perspectives (en tout cas sur Oracle ...) ?

left outer join en cascade par exemple, full outer join aussi.
ces fonctionnalités ne sont possible qu'avec la syntaxe verbeuse.

Ah oui en effet !