Reprise du message précédent :
dommage que l'auteur du topic ne poste plus, c'etait un sujet interessant...

 
Une procédure stockée consomme, au contraire, moins de ressource au serveur de données. Ca ne sera pas plus rapide sur l'execution de la requete à proprement parlé. Mais le moteur n'a pas besoin de refaire à chaque execution l'analyse syntaxique, verifier l'existence des sources et champs, la validité de la requete, et le plan d'execution à adopter. Il le sait dejà. C'est là que ca consomme moins de ressource.
 
C'est d'autant plus vrai que la requete est rapide en execution.

à mon sens la tu parle de prepare statements et non de procedures stockées

Non de procedures stockées comme tu peux en trouver sous sybase, oracle, ou sql server.

ok je ne connais pas bien ces sytemes.
pour moi un prepare statement (au sens mysql ou postgres, mais il me semblait que c'etait un truc plus standard que ca, car c'est par exemple une methode de DBI, le driver base de donnée de perl) c'est justement le fait de permettre au moteur d'alayser une bonne fois la requete (parsing SQL, optimization, indexes à utiliser, etc...) puis ensuite d'utiliser cette requete "précompilée" autant de fois que necessaire avec des données differentes.
Au contraire une procedure stockée est à mon sens un bout de logique qu'on va mettre à l'interieur de la base de donnée, comme par exemple un traitement particulier sur les données. En ce sens, j'aurais presque envi de considerer les fonctions genre average ou meme les autoincrement comme des sortes de procedures stockées "standards" (des sortes de presets), et d'ailleus si je ne me trompe en Oracle un autoincrement n'est rien d'autre qu'une procedure stockée en trigger qui va incrementer une sequence.

le prepared statement, c'est juste de définir un moule de requete où la structure est faite. Il n'y a plus que les cases de valeur à remplir. Un truc du genre:
 
la requete toto est  
 

 
et on appelle toto par
 

 
Le moteur remplace les valeurs dans les bonnes cases. Du coup la requete est analysée et, il me semble, que c'est plus fiable que de passer le code SQL en live. Ca evite de faire de injection SQL dans les parametres.
 
La procédure stockée offre une plus grande programmation autour du SQL. On peut faire la requete toto en procédure stockée avec un truc du style:
 

Bon l'écriture n'est pas bonne c'est simplifié.
 
Là on aurait le même résultat que le prepared statement. Par contre, dans la procédure, rien ne t'empeche de tartiner 10 000 lignes de code, dont des focntionnalités que tu ne pourras utiliser qu'en proc. Elles ne sont plus de l'ordre de la norme SQL.
 
Ensuite, je ne sais pas si les prepared statement sont compilées à l'avance? Ou seulement analysée par avance.

ils sont compilés (SQL parsé, indexes choisis, etc...) pour les version "recentes" (genre 4) de Mysql par exemple (et je pense pour les autres  bases aussi)
 
Par exemple dans DBI (le driver universel de base de donnée pour perl) tu a une interface prepare et chaque driver specifique (mysql, pg,...) peut on nous l'implementer.
Si il ne la réimplemente pas (c'est à dire si sont moeur ne sait pas en tirer profit) alors ca permet deja, comme tu le dis, de quoter proprement les valeurs au lieu de les foutre comme un porcs dans le SQL et ainsi eviter les erreurs.
 
Il faudrait que je regardes les differents DBD (drivers specifiques pour chaque base de donnée, pour DBI) pour voir lequels implementent cette methode. Pour Mysql c'est sur et pour pg il me semble aussi.
Le gain en vitesse est tellement important en utilisant cette fonction que je pense que la plupart des "grosses" sgbd l'implementent

En fait, un prepared statement est une procédure stockée en SQL dont la durée de vie est limitée. Généralement à la durée de la session.

on ne peut pas faire des prepared statement definitif. Je ne vois pas trop l'interet de la chose du coup si ca ne sort pas de la session. A moins de l'utiliser enormement de fois. Ce qui risque de ne pas etre le cas pour un site web.

Automatiser l'échappement des données injectées (parce que je veux pas être méchant mais les conneries genre mysql_real_escape_string hein ) et cacher temporairement les queries simples.
 
Une procédure stockée c'est pas une query simple, c'est pas du SQL et ça génère des traitements complexes (voir très complexes)

Non ce n'est pas ce que je voulais dire. Je lis qu'une prepared statement a une durée de vie limitée à la session. Je le comprend comme: il faut la declarer à chaque session pour pouvoir l'utiliser ensuite. Si c'est le cas, je ne vois pas l'interet.  
 
Bien que je pense que le prepared statement est déclaré une fois pour toute. Sinon je ne vois pas l'interet.

Non, il n'est pas déclaré une fois pour toute. Par contre, si tu ne vois pas son intérêt, c'est ton problème.

On va rester calme stp. Je ne vois pas l'interet de devoir redeclarer une structure a chaque session. A moins que de ne pas avoir la bonne notion de session. Est-ce qu'un appel d'une page PHP avec connexion à MySQL est une session? Si c'est le cas, tu vas devoir redeclarer le prepared statement que tu utilises à chaque appel de page. Je ne pense pas que sur une page on appel plusieurs fois la même requete. D'où le fait que je ne vois pas l'interet. Hormis le coté securité bien sur.

Pouvoir l'utiliser plusieurs fois par session sans avoir besoin de la redéfinir
 
Non parce que je ne sais pas si tu te rends compte, mais quand tu effectues des requêtes sur la DB sans prepared statements tu ne les redéfinis pas une fois par session mais une fois par requête
 
En plus j'ai l'impression que tu vois la création d'un prepared statement comme un truc gigantesque alors que c'est à peu près aussi contraignant que l'exécution d'une requête classique

Non, je ne vois pas la chose comme etant un truc gigantesque. L'usage que j'ai de MySQL est pour du WEB et rien d'autre. Il faut dejà avoir besoin d'executer plusieurs fois la même requete lors de la construction d'une page. Ce que je n'ai jamais.
 
Par contre, j'ai un peux zappé le but du topic. Je n'ai vu l'interet des prepared statement que dans mon cas.

Ou ne pas vouloir se briser les couilles à échapper manuellement chaque donnée injectée à coup de mysql_real_escape_string...
 
Enfin bon le problème n'existe qu'en PHP dans la mesure où c'est l'un des rares langages assez mal foutus pour offrir quelque chose d'autre que des prepared statements dans ses interfaces de DBs, et à forcer à injecter manuellement ses valeurs dans ses requêtes

je sais pas, mais je me casse pas le cul a tout verifier. J'ai une classe qui fait le boulot pour moi. Apres, je suis d'accord pour l'aspect sécurité de la chose. C'est d'ailleurs le seul interet que j'y vois avec du PHP.

Tout d'abord merci à tout ceux qui ont répondu.
J'ai cherché comment gérer autant données, et je suis arrivé à quelques conclusions :
-je suis toujours avec MySQL, et j'ai voulu tester la montée en charge. J'ai donc mis 200 Millions de lignes dans une table avec des valeurs aléatoires pour les 18 champs de cette table. J'ai testé beaucoup de requêtes avec retour unique (COUNT, SUM, AVG...). Sans avoir défini d'index, le temps de recherche est extrêmement long. Par contre, avec un index défini sur 16 champs (16 est le maximum), on arrive à un temps tout-à-fait correcte voisin du dixième de seconde (!). MySQL est vraiment extraordinaire !
-Mais le problème est essentiellement lié à la sécurité : en effet, toutes les données sont stockées dans un fichier de 4 Go, et tous les index pareil dans un fichier de 4 Go, ce qui est assez dangereux. De plus, lors de la mise en base, il ne faut garder que l'index PRIMARY, et recréer les INDEX à chaque ajout de données. Problème : à chaque session d'ajout de données, je dois donc le supprimer (20 Min) et le recréer (20 Min). Donc beaucoup trop coûteux en temps. De plus, j'ai testé avec 200 Millions de lignes, mais quid de 1 Milliard de lignes ?
-Finallement, j'ai trouvé une solution qui colle parfaitement à mon problème. Comme je dois faire des statistiques journalières, j'ai tout simplement créé une table par jour qui contiendra 2 Millions de lignes.
Ma base MySQL contiendra donc 365 tables de 2 Millions de lignes, et je suis gagnant sur toute la ligne : rapidité, sécurité, insertion des données, etc.
J'espère avoir été assez clair, n'hésitez pas si vous avez des questions.
Merci encore à tout ceux qui ont répondu, et je continuerai à faire part de mes recherches dans ce domaine.

 
[blague]
 
On a trouvé le web-looser d'IGN.  
 
[/blague]

[Re-blague]
Il dit qu'il voit pas le rapport.
[/Re-blague]
 
Merci pour le compliment, mais j'ai pas la prétention de bosser chez IGN

 
dommage  
 

 
oublie DB2 aussi, sauf si tu as un mainframe a disposition.
 
Reste SQL Server ou Oracle.

 
... ou encore MySQL qui a l'avantage d'être gratuit. Quand à SQL Server, il paraît que c'est vraiment pas une bonne idée quand il y a une grande quantité de données.
Par contre pour Oracle, je sais pas trop...

Si SQL Server ne convient pas, alors mySQL non plus ne conviendra pas... ce n'est pas parce que c'est gratuit que c'est mieux hein
Bien au contraire...

Ce n'est pas parce que c'est payant qu'on est sur d'avoir un outils meilleur. Bien au contraire.

Les deux théories se valent. Quand on regarde Linux et le nombre de développeurs qui y ont participé, on comprends pour cet OS est si efficace.
Dans la même idée, je pense que MySQL vaut largement, voire mieux que ses collègues payants.

Clairement pas La v5 commence à ressembler à un vrai RDBMS, mais c'est loin d'être la panacée.

 
mwouai... Pas sûr que ce soit mieux chez les concurrents payants... Quand on voit les problèmes avec oracle et les dernières statistiques le concernant...

Je doute que MySQL soit assez mature que ses homologues. Mais il est assez naif de penser que payant implique de qualité.

 
Payant ou gratuit, le problème n'est absolument pas là. Open source ou non open-source par contre, ça peut changer bien des choses, surtout quand on parle de programmes utilisés dans des millions de conditions différentes. En effet, une équipe aussi compétente et bien foutue soit-elle, n'a jamais les ressources pour gérer tous les imprévus alors que lorsque le programme est en open-source, n'importe quel progreux peut voir ce qui cloche en fonction de son utilisation.
 
C'est pour cela que pour des applications comme des OS ou des BDD, je trouve moi très bien que ce soit en open-source, c'est assurément un avantage. Que la couche graphique d'OSX ne soit pas libre, à la limite on s'en fout, que le système de base le soit, c'est tout de suite bien mieux.  

mouais, en open source t'as ptet 20 000 coder dans leur coins mais t'auras 20 000 versions aussi...

wtf

 
Plait-il ??
 
T'es un rigolo toua.    

Tu ne dois pas maitriser tous les concepts. Vois-tu 20 000 versions de MySQL se balader en ce moment

ou 20000 forks du noyal linux, ou d'apache, ou de PostgreSQL, ou d'Adium, ou de Kopete, ou de Gnome, ou de Xorg, ou de...

vous etes mignons

tu te defend bien

 
merci, pas toi.  

 
ah, une attaque ad hominem....

Je pense que Tamahome se refère un peu au phénomène "mon mien il est mieux que ton tien" souvent assez en vogue parmis les linuxiens ... Notamment le fait d'avoir X types differents de gestionnaires de bureau, messagerie,... Parcontre je comprend pas vraiment en quoi c'est un problème

 
bah parle pas de MySQL dans ce cas
 
Sinon, cela n'est plus vrai, M$ a rattrapé son retard par rapport à Oracle