Bonjour à tous,
 
Je me posais la question de savoir quel était la meilleur méthode pour gérer la connexion SQL à partir de PHP ?
 
1er solution :
A chaque début de page php :

Ensuite on peut faire une requête avec l'instruction mysql_query.
 
2nd solution :
Lorsque l'on a besoin d'une requête, on ouvre seulement à ce moment la connexion au serveur :

Laquelle de ses solutions est la plus intéressante (en terme de programmation, sécurité, ...) ? Qu'en pensez-vous ?
Avez vous d'autres solutions ?
 
Merci!

perso je vote pour la 2nde. point de vue sécurité, ya pas forcément de plus, mais point de vue technique, une requête ça prend qq millisecondes, ya pas besoin d'avoir une connexion ouverte hyper longtemps.
 
Maintenant dans la 2nde, je ne mettrais pas les identifiants, je les mettrais plus dans un fichier à part, bien protégé, et j'y ferais appel dans cette fonction.
 
Par contre, dans la 2nde, ne pas afficher de "or die $requete, ça ne sert à rien de faire @mysql_query si c'est pour dévoiler toute la structure derrière ... Vaut mieux la capter et l'envoyer par mail.

sinon ya d'autres manières, via un singleton par exemple. Seulement je ne sais pas si ça apporte un réel plus, et si oui, sur quels plans.

La 1ère sans aucun doute..
Ce qui prend le plus de temps (pour des requêtes simples) c'est l'ouverture/fermeture du lien avec la bdd .

Merci pour vos réponses, je pense que je vais opter pour la seconde qui permet vraiment de sécuriser l'accès à la base SQL.
NewsletTux : qu'est ce que tu entends dans "un fichier à part, bien protégé" ? Personnellement, je déclare ces constantes dans le fichier même.
Pour les "or die", c'est juste pendant mes tests, mais tu m'a donné l'idée du mail qui est pas mal...!

Solution n°2, employée à tords et travers depuis 3 ans pour ma part ..
j'ai pratiqué de nombreux benchmarks et le fait d'ouvrir/fermer la connexion, c'est peanuts sur le timing ..

Si tu souhaites gagner du temps sur tes requetes il faut regarder du côté de SQL_CACHE et la structure de ces dernières
( oui on peux updater, selectionner plusieurs tables à la fois, renommer les variables, faire des association toussa )

mysql_close est appellé par la fin de ton script ou ton timeout sql .. le mien est tjrs de 1 sec
   ( si ton sql local est down, ton script doit pas patienter 60 sec que restart ton sql )

PHP/MySQL ne gèrent pas le pooling
 
Parceque point de vue propreté/sécurité/montée en charge, justement la 2° est de loin meilleure quand on fait du pooling. Ca évite de conserver des connexions réservées pour rien pendant des traîtements de longue durée et surtout ça évite d'oublier le close en fin de page et finir par atteindre le nombre de connexion concurrentes maximales autorisées...

Salut,
 
Il y a un moment j'avais vu un bout de doc qui semblait dire que PHP gère de manière un minimum intelligent la connexion avec MySQL (Par exemple, si tu exécutes 2 fois dans le même script mysql_open, il n'effectuera que le premier), cependant si je me rappelle bien, si on enchaine les open/close , là il ne gère rien du tout et perd pas mal de temps .. Maintenant je dis ça de mémoire ..

Peut-être avec PHP faut-il passer par des fonctions explicites (ou un paramètre ?) mais de mémoire PHP / MySQL gèrent le pooling.
 
Et le pooling, justement, ça rajoute une couche entre la connexion à la base et le programme.
 
Quand ton programme demande au pool une connexion, une connexion libre est piochée dans ce dernier, ou une nouvelle est ouverte.
Quand ton programme ferme une connexion, la connexion retourne au pool marquée comme libre, mais ne se fermera que si un grand nombre de connexions libres le sont pendant trop longtemps.
 
Et piocher dans le pool est pour ainsi dire instantané.
 
Du coup, tu peux n'avoir qu'une réelle connexion à la base alors que tu as 20 visiteurs sur ton site. Et à aucun moment ton site ne s'amuse à ouvrir/fermer des connexion à la base à tout bout de champ.
 
Le gain en performances est énorme, aussi bien pour le site (moins de mémoire occupée, moins de temps perdu en négociation réseau, etc.) et pour le serveur (moins de sessions ouvertes)
 
A vérifier, mais il me semble que php gère ça tout à fait naturellement. Peut-être faut-il par contre activer une option dans le fichier de config, ça c'est pas impossible.

En googlant un peu j'ai trouvé ça :  
 
http://www.mysqlperformanceblog.co [...] ions-evil/
 
Il y a écrit que PHP/MySQL ne supportait pas (en tout cas à l'époque) le pooling .. Faut voir si ça a changé

A lire (j'ai lu que le texte, j'ai pas suivi les liens où tout devrait être expliqué)
http://www.nexen.net/actualites/tr [...] rmants.php

voilà
 
donc c'est les mêmes fonction, mais avec des "p" partout :
 
http://fr.php.net/function.mysql-pconnect
 
ceci dit, c'est pas du vrai pooling. c'est juste de la persistance : tu ouvres X connexions qui restent tout le temps ouvertes.
 
le seul souci, c'est que si tu as une page qui dure 2 minutes à s'exécuter alors qu'elle ne fait qu'une pauvre requête au tout début, tu vas quand même réserver la connection inutilement jusqu'à la fin du script. le pooling proposerait aussi un pclose() pour forcer la remise en pool.

D'accord, mais à ce que je comprend, on doit implémenter nous même une couche de persistance (via sqlrelay par exemple) pour que PHP puisse en bénéficier?

Edit: Oui mais les permanent connections ont été supprimées dans MySQLi pour les raisons expliquées dans mon lien

ah ok.
 
ben donc mysql c'est d'la merde et php aussi. (y savent plus quoi inventer pour paraître de plus en plus minable à mes yeux ceux-là...)
 
en .NET avec SQL Server ça le fait nativement et ça te demande même pas ton avis

Comme d'habitude, ça dépend de ce que tu cherches  
Si t'as besoin d'un site qui gère un DB de plusieurs centaines de GB avec des millier de hit/sec , c'est clair que PHP/MySQL ne serait pas mon premier choix. Mais je trouve totalement stupide pour une startup de 15 personnes d'investir dans des licences MS à la chaine pour avoir tout l'environnement Windows Server + SQL Server alors qu'ils auront 100 hit / jour si tout va bien

t'as besoin ni de windows server ni d'une version sql server standard pour héberger un site qui fait 100 hits par jours
 
1 licence à 100 € pour un vista family avec sql server express et t'as pas besoin d'un centime de plus... et au moins même la concierge elle peut le rallumer en cas de coupure de courant le week-end

Bah pour 100€ de moins tu déploies vite fait un apache + php + mySQL sur linux (pas venir me dire que l'install est difficile.. Sur Debian c'est fait en 3 commandes + 5 lignes de config dans les bon fichiers).
 
Et au pire tu les investi dans un onduleur qui va te faire un soft shutdown en cas de pépin avec le courant

et qui coûte 500 €
 
et ça explique toujours pas à la concierge comment redémarrer le bouzin qui arrête pas de beeper toute la nuit

Va faire un tour sur OSA, il y a justement en ce moment un topic sur des serveur basse puissance qui se branchent sans problèmes sur un onduleur à 100€ .
La concierge veut reboot ? Aucun problème, tu config le bouton supprimer pour que ça lance un "reboot" est c'est réglé .. La concierge peut dormir tranquille
 
Mais bon de toutes façons là on s'éloigne du problème ..

Merci pour toutes vos réponses!
Effectivement vous vous éloignez du problème...
 
Je vous avoue que j'arrive pas trop à suivre vos discussions et à en déduire laquelle solution est la mieux !
 
Je vous posais cette question pour une petit application php/mysql qui va gérer les téléchargements de fichiers sur un serveur Free.

point de vue "age de développement", c'est la seconde qu'il faut utiliser.
elle permet de n'utiliser la base qu'aux moment où on en a besoin.
 
mais la première, qui date d'un autre age, comme le cerveau des développeurs de PHP et MySQL, est plus performante pour le couple PHP/MySQL uniquement. c'est un peu comme si t'as le choix entre un cheval pur-sang et une mobilette... le cheval court plus vite, m'enfin voilà quoi...

Je suis pourtant d'un autre age, cerveau usé, corrodé et rouillé, et j'utilise la seconde depuis des années  

pour un serveur Free, oublie le mysql_pconnect : ils ont désactivé les connexions persistantes.

Moi je vote pour la 1ere.
 
Dans la version de code que tu donnes il manque des choses.
C'est bien beau d'ouvrir le connexion et de la refermer mais si tu veux faire un mysql_insert_id il faut le faire sur la connexion en cours par exemple.
 
De plus plus le nombre de requete effectuée dans le script grossit plus la première solution devient interressante.

Il est vrai que si tu concois bien ton application, tu fais les requetes sql le plus rapidement possible, tu construis ta page, puis tu ferme la connection
Les deux méthodes sont valables tout de meme, j'ai de meilleurs résultats avec la seconde, personnellement  

 
Pourrait tu me dire ce que tu entends par de meilleurs résultats ?

en lancant un chrono

Tu dis donc que : tu va plus vite en ouvrant/fermant la connexion X fois plus qu'en ne l'ouvrant/fermant qu'une fois ?
(avec X = nombre de requetes)

tu n'es pas obligé de fermer la connexion dans le seconde exemple, la fin du script l'opère ou un mysql_timeout de 1 sec y remédie largement

Je vois pas l'interet de passer par le 2eme méthode si tu refermes pas la connexion à chaque fois ...

L'intérêt est de ne pas ouvrir de connexion tant qu'on en a pas besoin.

Parfaitement, et le nombre de scripts que j'ai repris à ce jour qui ouvraient la connexion dans le header, et n'en faisaient rien ..
saturent le nombre de connexion sql à un site faisant > 1300 visiteurs / jour ..

sans compter ceux qui utilisent mysql_pconnect ..
donc suffit ces 2 cas, et un mysql_timeout jamais configuré pour rapidement saturer un site

2 visiteurs par minutes (j'ai considéré qu'il y avait plusieurs heures sans visite dans la nuit) et la base est saturé? C'est quoi ces sites mal conçu?
 
PS : C'est fou le nombre de sites programmé avec les pieds, j'en ai croisé deux trois bien gratiné moi aussi.

Vous ne répondez pas a ma question, je vous demande l'interet d'inclure la connexion dans la fonction REQUETE si vous ne fermez pas la connexion. Car lors du second appel a la fonction vous allez rouvrir un connexion.
 
Pour ce qui est de n'ouvrir la base que lorsqu'on en a besoin il suffit de faire un singleton qui ouvrira la base a la première connexion et pas aux suivante et qui fermrra la base dans son destructeur par exemple.
 
Et puis je vous signale que lorsqu'on ouvre une base il faut aussi spécifier l'encodage de la connexion, ça aussi vous le multipliez pour chaque requête ? Je trouve pas que ce soit une bonne méthode ...

l'intérêt d'inclure la connexion à la base à l'intérieur d'une fonction "requete", c'est de centraliser les accès à la base dans un seul fichier (plus facile à maintenir, gérer les traces, statistiques, etc.) et surtout de débordeliser le code du programme sans le charger inutilement.
 
c'est aussi la garantie de toujours fermer proprement la connexion quand on n'en a plus besoin.

Toujours pas ... c'est pas grave

et tu veux quoi comme réponse ?
 
parceque si d'après toi je t'ai pas donné mon point de vue sur l'utilisation de ta fonction requête, je vois pas trop ce que tu demandes...

C'est simple, que les gens fassent leur expériences mutuelles ( de méthodes de connexion à leur Bdd )
qu'ils l'expérimentent grandeur nature sur un mutualisé ( majorité des petits sites ) avec plus de 1000 visiteurs
et plus qu'à collecter leurs avis sur comment un site doit être optimisé ( mais on n'aborde pas le SQL_CACHE c'est dommage )

( je connais des gens qui parviennent à saturer des dédiés quadriproc et 2go de ram .. )

Si tu veux saturer n'importe quel serveur, aucun souci, utilise la première méthode. C'est ce qu'on te dis depuis le début
 
Ouvrir une connexion en début de page et ne pas la refermer, c'est s'assurer que le serveur d'application va parfois oublier de fermer proprement la connexion, et provoquer des sessions fantôme sur le SGBD
 
Je suis intervenu il y a quelques temps chez un client justement pour réécrire toute la partie accès aux données d'un site intranet. Le site en question était utilisé par 5 ou 6 personnes, et quelques heures suffisaient à faire planter le serveur Oracle de l'ERP, qui lui était pourtant utilisé sans sourciller par quelques centaines de personnes, de façon bien plus intensive que l'intranet...

Moi qui croyait prêcher dans le désert à une certaine époque ..
détournement de topic, je cherche à optimiser cette requete ( le traitement gère plus d'un milier d'enregistrements similaires )

 - J'ai une table "internes" qui contient les voeux des personnes ( les identifiants listés dans l'ordre ), ce qui correspond au id in(x,y,z), dont le Reste>0 order by case id (ouch)
> mon but et d'obtenir le premier voeux dont le reste > 0 dans l'ordre des voeux de la personne et raccourcir au maximum les requetes
le Must serait de tout passer via Sql, autant rêver

Une fois une correspondance trouvé j'update le "SpeMed.Reste=SpeMed.Reste-1"
et ça mouline pour plus de 1000 personnes à chaque fois ..

Qq'un dispose d'une belle lanterne ?