Bonjour,
 
Actuellement sur la création d'un site petite annonce, je sollicite votre avis afin de savoir quel méthode appliquer entre faire des views ou procédure stockée.
 
En effet, lors de l'enregistrement des annonces, ces dernières sont stockée dans une "table 1" et les critères optionnels liés a ces annonces dans une "table 2"
 
Ma question est de savoir:
 
Quelle méthode est la plus efficace en terme de rapidité d'exécution et de sécurité.
 
NOTE: dsl pour ce manque d'information, je ne suis pas expert en sql, simplement que j'ai affaire a deux développeurs qui me soumette chacun une expertise différente
 
Merci d'avance pour vos réponses

Quand il s'agit d'optimisations, il faut tester.
 
A priori, par expérience, je dirais que la solution 1 prendra quelques fraction de secondes, et la solution 2 prendra fractions de secondes. Est-il vraiment nécessaire de les départager sur le critère de la vitesse d'exécution ?
 
Quand il s'agit de sécurité, il faut penser aux maillons faibles.
Les maillons faibles sont les absences de surveillance, les absences de sauvegarde, les portes d'entrées et de sortie.

Donc selon vous, le rapport vitesse d'excution (retour client) est kiff kiff entre les vue et les procédures stockées.
 
Sur mon site, les recherche seront effectuées de façon fréquente car axe principale du site d'ou mon besoin de rapidité et de stabilité même si j'ai conscience que ce facteur influe aussi au niveau de la config du serveur.
 
Quant à la sécurité, que préconisez-vous?

Dsl mais je n'ai pas bien compris votre phrase
 
""A priori, par expérience, je dirais que la solution 1 prendra quelques fraction de secondes, et la solution 2 prendra fractions de secondes. Est-il vraiment nécessaire de les départager sur le critère de la vitesse d'exécution ? ""

Je répondrais :
 
Aucune des deux.
 
Les vues servent à des fins de visualisation, elles représentent pour moi un non sens, une hérésie du SQL.
 
Les procédures stockées sont destinées aux développeurs MySQL, autrement dit aux pauvres qui ne bénéficient pas de la puissance d'un vrai langage de programmation (PHP... etc.)
 
Si tu souhaites des résultats qui se chargent rapidement, il faut utiliser du cache fichier ou mieux du cache mémoire distribué de type Memcached.
 
Dans tous les cas, l'optimiseur MySQL gardera en mémoire une empreinte de tes requêtes (Essayer une requête une première fois avec SELECT SQL_NO_CACHE... -version non cachée-, une seconde fois avec SELECT... -version cachée- et comparer la vitesse d'exécution), et ceci tout particulièrement dans le cas d'une requête préparée, ce qui se fait très bien avec l'API PDO (PHP).
 
 

Merci pour le fou rire matinal.

Pourquoi ?
 

 
Quid de l'application des procédures stockées à la conservation de l'intégrité et de la cohérence des données dans la base ?

Je pense que tu ferais mieux de te taire, plutôt que d'induire les gens en erreur avec ton ignorance.

 
J'avoue ne pas comprendre ce raisonnement. Je pense sincèrement que cela dépend du besoin rencontré, en l’occurrence un site de petite annonce sert bien à la consultation des annonces.
 
Le souci pour moi est surtout la robustesse de l'appli car le fait de rechercher quelques chose sous entend un grand nombre de requête exécuter coté serveur d'où ma question sur la rapidité et la sécurité (injection sql, etc...)

 
J'avoue ne pas comprendre ce raisonnement. Je pense sincèrement que cela dépend du besoin rencontré, en l’occurrence un site de petite annonce sert bien à la consultation des annonces.
 
Le souci pour moi est surtout la robustesse de l'appli car le fait de rechercher quelques chose sous entend un grand nombre de requête exécuter coté serveur d'où ma question sur la rapidité et la sécurité (injection sql, etc...)

Si tu es en cours de conception de ton site la rapidité n'est pas le problème à considérer pour l'instant. La priorité est d'avoir un truc qui fonctionne, et de bien définir tes clés et indexes - l'optimisation tu la feras plus tard si tu en as besoin.

Merci pour la réponse
Actuellement le site est héberger afin de testé sa réactivité online. La ou j'ai peut être pas assuré est de l'avoir mit sur un mutualisé au lieu d'un dédié ce qui effectivement boosterai sa réactivité.
 
Ce que je souhaite vraiment savoir:
Quand plusieurs information sont dispersé dans deux tables différente; est il plus judicieux d'utilisé des vues ou une procédure stockée pour ramené l'information?
 
Les vues ne représente elle pas un risque au niveau sécurité.
 
Car j'ai deux développeur sur le sujet qui chacun oriente leurs choix vers l'une ou l'autre des solutions énoncé.
 
Donc j'aurais voulu avoir des avis extérieurs afin de statuer sur la méthode a conservé.

 
Le plus judicieux c'est de faire une simple jointure, et de voir plus tard s'il y a mieux à faire.
 

Non.

Merci Skeye pour ta réponse

skeye, sauf que bien souvent quand tu résonnes en te disant, je vais faire un truc super pas optimisé pour gagner du temps et on verra, tu te rendras compte au bout d'un moment que ça te prendra le double de temps à reprendre tout ton code après pour l'optimiser (dans le meilleur des cas)  
 
ou alors tu laisseras le code tel quel.
 
Dans tous les cas je te conseille de faire quelque chose de propre d'entrée de jeu et le maximum côté MySQL plutôt que coté PHP.

Il peut y avoir un large fossé entre "propre" et "optimisé". Il n'y aura pas grand chose à optimiser dans une requête sur deux tables si c'est fait proprement dès le début.

 
Dans la majorité des cas, mettre les bonnes clés étrangères et des indexes là où il faut suffira à obtenir de bonnes perfs.
S'il a besoin de plus que ça il ne le verra qu'à l'usage, ce n'est pas le moment d'y penser.

 
Cela me semble censé, d'autant que je peux attribué des clés étrangères aux catégories de produit disposant de critère specifie tout en construisant des "vues" de la meilleur façon possible

 
Aussi d'accord avec ce raisonnement, autant oeuvré dès le début afin de gagné du temps