Reprise du message précédent :
Ce sont des requêtes paramétrées. Le principal intérêt étant qu'on prépare une fois pour toutes la requête lors de l'exécution d'un script, et qu'à chaque exécution de la requête on se contente de fournir les paramètres, rendant le tout beaucoup plus rapide...

C'est un état intermédiaire entre le SQL intreprété et le SQL emabrqué. En gros, tu donnes une query avec des variables, la query est préprocessée autant que possible et ensuite tu lui demandes de s'éxécuter en donnant des valeurs à ces variables. En général c'est plus rapide que le SQL intreprété et ça a l'avantage de pouvoir répéter plusieur fois la query en ne changeant que les valeurs des variables.

Et ça empèche les injections SQL ta soluce ? En fait le must, ça serait une requête (ou une fonction) qui permette d'éviter une bonne fois pour toute les injections parce qu'avec le is_numeric(), faut la mettre à chaque endroit où on veut éviter qu'il y en ait je suppose

 
en effet  

oui, ça les empèche. Et puis y a aussi les PDO qui fonctionnent bien.

 
Bon en même temps je débute donc je peux optimiser le code au fur et à mesure  
 
PDO, kézako   ?

T'as déjà lu la doc de php?

A vrai dire non, j'ai appris le PHP en lisant des bouquins et modifiant les exemples qu'on y donne...

OU  
 
Le but des prepared statements est justement de se débarasser de ces fonctions d'escaping manuelles à la con

C'est l'interface DB-agnostic avec prepared statements de PHP 5.1 ça non
 
Celle où on est obligé de binder chaque argument manuellement au prepared statement  

oui, c'est celle-la. Par contre, je ne vois pas bien comment tu voudrais faire pour que le truc devine comment tu veux faire ton binding.

youp,
 
Je ne comprends pas trop à quel moment ca se met en place. Comment demande-t-on à la query de se préprocesser ?
En gros, ca marche comment concrètement (le principe je pense avoir pigé ) ?
 
Sinon la question qui tue : c'est quoi SQL interprété et SQL embarqué ? ce sont les requêtes et les "fonctions" internes ?
 
 
 
Désolé de ma neuneunitude

Le SQL intreprété, c'est ce que tu as quand tu fais un truc comme mysql_query(requète). C'est un one-shot, tout est interprété au run-time. Le SQL embarqué, c'est le contraire, c'est une requète que tu compiles et que tu ajoutes, généralement sous forme de fonction,directement à ton serveur SQL. Au milieu, tu as les prepared statement (et les strored procédure).  
Quand tu demandes de faire un prepared statement, il est envoyé au serveur et celui-ci peut déjà calculer les valeurs acceptables pour les variables te comment organiser ses jointures ou utiliser ses index. Ensuite, quand tu envoies les variables, il fait tourner directement le bouzin, ce qui fait que c'est généralement plus rapide.

Et moins risqué alors ?

perso j'utilise PHP + mise en cache

Bah oui. Par exemple si tu mets fais une query comme cela:
 
SELECT * FROM table WHERE champ = ?
 
et que champ est du type texte, tout ce que tu injecteras comme contenu dans la variable qui lui sera assigné sera formatté comme tel. Ainsi, si tu essaies de mettre "valeur' OR 1=1", ce sera automatiquement tranformé en "'valeur'' OR 1=1'", et plus de risque d'injection.

Euh, dites-moi, pour selectionner tous les sujets en affichant aussi les drapeaux je dois utiliser LEFT JOIN?
 
C'est ce que j'ai fait, j'ai fait un truc du genre
SELECT  *
 FROM sujet LEFT JOIN drapeaux ON sujet.id=drapeaux.id_post
 
Mais ca me met une erreur
La syntaxe est correcte?

Ca m'a pas l'air bon ça... Moi j'aurais plutôt fait ça:
 

 
Si le champ a le même nom dans les deux tables, faut aliaser les tables utilisées. Et même sans ça, c'est toujours mieux de le faire quand on utilise plusieurs tables, ça évite de s'emmêler les pinceaux!

Je voudrais éviter de faire des s d . etc...
Avce les vrais noms ca ne fonctionnerait pas?
Edit: Dsl je suis embetant  

Ca marche, mais je voudrais faire un peu plus compliqué.
 Je voudrais selectionner que
-les drapeaux ayant un membre=$_SESSION[login]  
-les sujets ayant le champ id_categorie=$idcat
Je sais pas trop où placer ca ...

simplement dans la clause WHERE.

SELECT  s.*,d.*  
      FROM sujet s   LEFT JOIN drapeaux d ON d.id_post = s.id  WHERE d.membre="'.$_SESSION[login].'" AND s.id_categorie="'.$cid.'"'
?
 
On dirait que ca m'affiche bien ce que je veux, mais ca m'affiche seulement les champs sujets qui ont une occurence avec le champ drapeau

merci

 
Et en utilisant LEFT OUTER JOIN au lieu de LEFT JOIN?

Un lien qui explique le fonctionnement des prepared statements :
http://maximilian.developpez.com/m [...] tatements/

LEFT JOIN

 

 
Je te demande si en utilisant LEFT OUTER JOIN au lieu de LEFT JOIN ca te sélectionne tous les topics?

 
Je connaissais pas, je vais aller voir ça, m'enfin bon faire tout ça pour une simple requête de sélection, y'a de l'enculage de mouches inside
 
Edit après une rapide lecture : en effet, ça ne sert à rien dans le cas présent  

 
 
Ouais mais si l'utilisateur a à rentrer des choses plusieurs fois de suite ? (genre un texte à saisir par-ci, quelquechose à uploader par là), autant fixer la forme des requêtes une fois pour toute non ?
 
Surtout que :

Left OUTER JOIN ca ne m'affiche rien. Il doit y avoir un problème d'ardre dans la clause where, ou de position de la clause where

 
On parlait bien d'un forum avec une requête SELECT là non  

 
Oui oui, j'ai confondu

ok je me disais aussi ^^

Ben en Python avec une interface compatible DBAPI 2 on peut faire

cur.execute("INSERT INTO foo (bar, baz, buzz) VALUES (?,?,?)", (bar, baz, buzz))

Ou même

cur.execute("INSERT INTO foo (bar, baz, buzz) VALUES (%d,%s,%s)", (bar, baz, buzz))

(qui effectue une vérif des types depuis la couche Python)
Ou encore

values = {"bar":3, "baz": "jeanclod", "buzz": "pouet", "gnii": gnou, "frubs": 3}
cur.execute("INSERT INTO foo (bar, baz, buzz) VALUES (%(bar)d,%(baz)s,%(buzz)s)", values)

 
Et si tu veux exécuter plusieurs fois la même requête en changeant les valeurs, il y a un Cursor.executemany() qui fonctionne comme execute sauf que son 2e argument est une liste d'arguments à la query.

La définition est fausse, le but des prepared statements c'est de préparer les paramètres pour leur injection sécurisée dans la query, le fait de stocker la query et de pouvoir l'exécuter à répétition avec des arguments différents est un effet de bord et dépend de l'implémentation

cur.execute("INSERT INTO foo (bar, baz, buzz) VALUES (?,?,?)", (bar, baz, buzz))

cur.execute("INSERT INTO foo (bar, baz, buzz) VALUES (%d,%s,%s)", (bar, baz, buzz))

values = {"bar":3, "baz": "jeanclod", "buzz": "pouet", "gnii": gnou, "frubs": 3}
cur.execute("INSERT INTO foo (bar, baz, buzz) VALUES (%(bar)d,%(baz)s,%(buzz)s)", values)

 
Bah en php c'est pareil, si ce n'est que ça se fait en deux lignes, je vois pas vraiment la différence.
 

Non. Un prepared statement ne doit d'ailleurs pas obligatoirement contenir de paramètre. D'ailleurs, dans le fonctionnement normal d'un prepared statement, il est d'abord envoyé au serveur et ce n'est qu'après que les éventuels paramètres sont ajoutés. Je n'ai pas vérifié comment fonctionne les drivers mysql, mais je sais qu'au début de leur support, ils faisaient les manip côté client, ce qui en réduisait l'intérêt.

La dernière fois que j'ai regardé PDO et mysqli ça donnait une ligne pour la requête à préparer + une ligne pour chaque paramètre (un $bouzin->bind) + une ligne d'exec
 
Ca fait un peu plus de deux lignes, sur l'exemple que j'ai donné ça en fait déjà 5

Une ligne pour chaque paramètre, c'est en mode objet. En mode procédural, tu peux utiliser :
 

normal, t'as un WHERE sur d.membre.
 
SELECT  s.*,d.*  
      FROM sujet s   LEFT JOIN drapeaux d ON (d.id_post = s.id AND d.membre="'.$_SESSION[login].'" ) WHERE s.id_categorie="'.$cid.'"

values = {"bar":3, "baz": "jeanclod", "buzz": "pouet", "gnii": gnou, "frubs": 3}
cur.execute("INSERT INTO foo (bar, baz, buzz) VALUES (%(bar)d,%(baz)s,%(buzz)s)", values)

J'ai fait un truc dans ce style, tiens... Ca s'utilise comme ça :

 
Au départ, j'avais utilisé la première syntaxe (avec les ?), sauf que l'escape ne se fait pas de la même manière si c'est un identifier (utilisation de backquotes), un nombre (pas de quotes), ou une string....

T'aurais pu utiliser la syntaxe de printf
 
Et un execute qui renvoie null (ou l'équivalent en PHP) quand ya pas de résultats, comme ça t'as pas besoin de faire 15 fonctions différentes pour la même chose
 
Et ce que t'as fait ne fait absolument pas la même chose que ce que tu as quoté, l'équivalent ce serait de filer un array clé=>valeur à l'execute, toi t'as codé l'équivalent de la syntaxe 2.

Ouais, j'pourrais faire ça...

Et ouais, j'ai quoté le mauvais passage