Discussion :

[ForgetTheNorm]

Bonjour à tous

Je développe en PHP/SQL depuis plusieurs années déjà, en ayant appris par mes propres moyens. Ce que je fais fonctionne, mais je me pose des questions sur la manière "générale" de développement, pour savoir si ma façon de faire est bonne ou non. J'ai donc une série de questions, j'aimerai avoir vos avis/expériences sur la manière de faire.

1) La connexion SQL via PHP est située dans un fichier PHP à part, avec identifiants et mot de passe. Chaque fichier nécessitant de se connecter à la BD SQL fait un import de ce fichier. Je me pose des questions quant à la sécurité de ce genre de pratique.

2) La gestion et l'affichage des erreurs. Il arrive quelquefois que l'on s'aperçoive d'une erreur que tardivement dans la page (erreur SQL, erreur de paramètre, etc). Cependant, tout ce qui a été écrit précédemment (via echo ou print) n'a plus lieu d'être affiché. Ma méthode consiste donc à effectuer toutes les opérations générant possiblement des erreurs en tête de la page, sans rien afficher, en retenant les résultats dans des variables. Si il y a la moindre erreur, j'affiche un message d'erreur, puis exit. Sinon, j'affiche le contenu des variables. Est-ce la meilleure méthode ?

3) La complexité des requêtes SQL. Voilà une question plus vague ; des fois, j'ai besoin d'effectuer des requêtes SQL complexes (via triples - quadruples - quintuples jointures). Quelle est la meilleure méthode ?
- Effectuer cette requête complexe directement dans le code (lenteur à l'execution)
- Créer une vue spécifique pour simplifier la requête (lenteur à la mise à jour)
- "Découper" cette requête en plusieurs sous-requêtes, en combinant avec PHP


Voilà, c'est tout pour le moment, à vous.
Merci

Pierre

[JerryOne3]

Bonjour,

le fait d'avoir un seul fichier avec tes identifiants, c'est correct coté sécu, pas de problème.

Pour ce qui est des erreurs, ma philosophie diffère de la tienne : il te faut te demander si vraiment une erreur est handicapante au point qu'il soit préférable de ne rien afficher. Si c'est le cas tu peux toujours opter pour un tampon (ob_start) global plutôt que des variables, mais bon...

Enfin, ma méthode pour les grosses requêtes consiste à les écrire dans des fonctions à la fin du programme et return le mysql_query. Si tu travailles en objets, il pourrait être plus efficace de te créer une classe "requêteur". De toute façon, il faut minimiser les appels SQL : moins il y en a, mieux c'est. Donc non, pas de PHP au fur et à mesure. Le moins de requêtes possibles, donc le moins d'échange entre le serveur et la BDD, et après tu entames la gestion.

Cordialement

[juliens9]

Bonjour ForgetTheNorm,

Pour ce qui de la connexion via un seul fichier, aucun soucis à condition que le fichier se trouve dans un répertoire protégé en accès (seul apache doit avoir le droit d'accès)

Pour ce qui est des erreurs, je rejoins l'avis de JerryOne. Est-il plus mieux d'afficher du contenu avec quelques erreurs, ou ne rien afficher du tout ? Finalement la chose la plus importante c'est de suivre tes logs d'erreurs, pour pouvoir les corriger le plus rapidement possible et en avoir le moins souvent possible.

Pour ce qui est des requêtes SQL, il faut effectivement avoir le moins d'appels sql possible. Mais attention à certaines jointures qui peuvent se révéler catastrophiques en terme de performances (penses à bien vérifier des index concernés par tes jointures). Finalement le mieux c'est de voir si tu ne peux pas pré-calculer un certain nombre d’élément, et générer des tables de résultats, que tu mets à jour régulièrement. Après si ta requête est toujours la même ( ou change très peu), elle sera mieux en cache par ton SGBD, et il n'y aura aucun soucis de performances.
L'utilisation de php, peut se relevé efficace, pour éviter les requêtes imbriquées, mais à éviter dans les autres cas.

[ForgetTheNorm]

Merci à tous pour vos réponses constructives.

J'ajoute un point suivant auquel je suis rencontré. Pour faire simple, j'ai 2 tables, j'aimerai récupérer :
- une unique ligne sur la table 1 (avec tous ses attributs)
- l'ensemble des lignes de la table 2, avec une jointure sur mon unique ligne de la table 1.
Un exemple est une unique société A (une ligne de la table 1) dont on aimerait avoir l'ensemble des employés (table 2) de la société A.

Faut-il mieux passer par :
- une unique requête, avec l'ensemble des champs de la table 1 et de la table 2, et alors avoir une sacrée redondances sur les champs de la table 1
- deux requêtes, l'une pour obtenir l'unique ligne de la table 1, et l'autre pour obtenir l'ensemble des lignes de la table 2 (et donc là, pas de redondance)

Pierre