Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1002 connectés 

  FORUM HardWare.fr
  Programmation
  PHP

  Vue ou Procédure stockée

 



 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

Vue ou Procédure stockée

n°2085866
omaker
Posté le 29-06-2011 à 14:26:31  profilanswer
 

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

mood
Publicité
Posté le 29-06-2011 à 14:26:31  profilanswer
 

n°2085914
olivthill
Posté le 29-06-2011 à 16:34:17  profilanswer
 

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.

n°2085926
omaker
Posté le 29-06-2011 à 17:16:02  profilanswer
 

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?

n°2085927
omaker
Posté le 29-06-2011 à 17:18:17  profilanswer
 

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 ? ""

n°2085974
CyberDenix
Posté le 29-06-2011 à 23:17:46  profilanswer
 

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).
 
 


---------------
Directeur Technique (CTO)
n°2086026
skeye
Posté le 30-06-2011 à 10:08:24  profilanswer
 

CyberDenix a écrit :


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.)


Merci pour le fou rire matinal.:D


---------------
Can't buy what I want because it's free -
n°2086030
___alt
mvn -T 4C clean install
Posté le 30-06-2011 à 10:12:40  profilanswer
 

CyberDenix a écrit :

Les vues servent à des fins de visualisation, elles représentent pour moi un non sens, une hérésie du SQL.


Pourquoi ?
 

CyberDenix a écrit :

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.)


 
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 ?


---------------
Crack the Egg : escape game à Paris (Gare de Lyon) | "Wenn es einen Gott gibt muß er mich um Verzeihung bitten."
n°2086033
drasche
Posté le 30-06-2011 à 10:18:25  profilanswer
 

CyberDenix a écrit :

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).
 
 


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


---------------
Whichever format the fan may want to listen is fine with us – vinyl, wax cylinders, shellac, 8-track, iPod, cloud storage, cranial implants – just as long as it’s loud and rockin' (Billy Gibbons, ZZ Top)
n°2086035
omaker
Posté le 30-06-2011 à 10:19:13  profilanswer
 

skeye a écrit :


Merci pour le fou rire matinal.:D


 
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...)

n°2086036
omaker
Posté le 30-06-2011 à 10:20:09  profilanswer
 

CyberDenix a écrit :

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).
 
 


 
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...)

mood
Publicité
Posté le 30-06-2011 à 10:20:09  profilanswer
 

n°2086037
skeye
Posté le 30-06-2011 à 10:23:07  profilanswer
 

omaker a écrit :

 

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.


Message édité par skeye le 30-06-2011 à 10:23:44

---------------
Can't buy what I want because it's free -
n°2086039
omaker
Posté le 30-06-2011 à 10:33:06  profilanswer
 

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é.

n°2086043
skeye
Posté le 30-06-2011 à 10:40:18  profilanswer
 

omaker a écrit :


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?


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

omaker a écrit :


Les vues ne représente elle pas un risque au niveau sécurité.


Non.


---------------
Can't buy what I want because it's free -
n°2086046
omaker
Posté le 30-06-2011 à 10:43:54  profilanswer
 

Merci Skeye pour ta réponse

n°2086285
Antac
..
Posté le 30-06-2011 à 19:03:41  profilanswer
 

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.

n°2086288
drasche
Posté le 30-06-2011 à 19:07:13  profilanswer
 

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.


---------------
Whichever format the fan may want to listen is fine with us – vinyl, wax cylinders, shellac, 8-track, iPod, cloud storage, cranial implants – just as long as it’s loud and rockin' (Billy Gibbons, ZZ Top)
n°2086289
skeye
Posté le 30-06-2011 à 19:07:43  profilanswer
 

Antac a écrit :

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)


Citation :

Premature optimization is the root of all evil.


 
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.


---------------
Can't buy what I want because it's free -
n°2086456
omaker
Posté le 01-07-2011 à 12:04:15  profilanswer
 

skeye a écrit :


Citation :

Premature optimization is the root of all evil.


 
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

n°2086457
omaker
Posté le 01-07-2011 à 12:05:12  profilanswer
 

Antac a écrit :

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.


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


Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  PHP

  Vue ou Procédure stockée

 

Sujets relatifs
[résolu]Redéfinir la Procédure d'un Edit avec DialogBoxVBA Appeler procédure dynamique dont le nom est variable
Erreur dans l'appel d'une procédure stockée sous Visual C++ (6.0)Appeler une procédure dans une procédure
Problème de récupération de valeur d'une ListBox dans une procédureRegénération de MDP : ma procédure contient-elle des risques ?
Enregistrement d'un fichier texte dans une procédure récursiveMacro Excel: Pivottables: Argument ou Appel de procédure incorrect
Paramètre d'une procedure/function stockée 
Plus de sujets relatifs à : Vue ou Procédure stockée


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR