Méthode(s) de connexion SQL ?!

Méthode(s) de connexion SQL ?! - PHP - Programmation

Marsh Posté le 28-08-2008 à 23:39:10    

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 :

Code :
  1. @mysql_connect(HOST,USER,PASSWD) or die("<center><h2>Erreur de connexion au serveur.</h2><h4>Merci de vérifier les paramétres de connexion !</h4></center>";);
  2. @mysql_select_db(BDD) or die("<center><h2>Erreur de connexion à la base de données.</h2></center>";);


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 :

Code :
  1. function Requete ($requete){
  2.     //Connexion au serveur
  3.     @mysql_connect(HOST,USER,PASSWD) or die("<center><h2>Erreur de connexion au serveur.</h2><h4>Merci de vérifier les paramétres de connexion !</h4></center>";);
  4.     //Connexion à la base de données
  5.     @mysql_select_db(BDD) or die("<center><h2>Erreur de connexion à la base de données.</h2></center>";);
  6.     //Requête
  7.     $result = @mysql_query($requete) or die("<center><h2>Erreur dans la requête :</h2><h4>".$requete."</h4></center>";);
  8.     return $result;
  9.     //Déconnexion du serveur
  10.     mysql_close();
  11. }


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!


Message édité par Adrienm le 28-08-2008 à 23:40:04

---------------
Adrien
Reply

Marsh Posté le 28-08-2008 à 23:39:10   

Reply

Marsh Posté le 29-08-2008 à 00:25:55    

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.


---------------
NewsletTux - outil de mailing list en PHP MySQL
Reply

Marsh Posté le 29-08-2008 à 00:27:55    

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.


---------------
NewsletTux - outil de mailing list en PHP MySQL
Reply

Marsh Posté le 29-08-2008 à 08:12:04    

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 .


---------------
Si la vérité est découverte par quelqu'un d'autre,elle perd toujours un peu d'attrait
Reply

Marsh Posté le 29-08-2008 à 08:54:28    

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


Message édité par Adrienm le 29-08-2008 à 08:54:44

---------------
Adrien
Reply

Marsh Posté le 29-08-2008 à 11:04:50    

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 ) :D

 

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 )


Message édité par grosbin le 29-08-2008 à 11:06:37

---------------
Photos Panoramiques Montagnes Haute Savoie
Reply

Marsh Posté le 29-08-2008 à 15:13:51    

esox_ch a écrit :

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 .


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


Message édité par MagicBuzz le 29-08-2008 à 15:16:02
Reply

Marsh Posté le 29-08-2008 à 15:57:47    

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


---------------
Si la vérité est découverte par quelqu'un d'autre,elle perd toujours un peu d'attrait
Reply

Marsh Posté le 29-08-2008 à 16:04:20    

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.


Message édité par MagicBuzz le 29-08-2008 à 16:05:59
Reply

Marsh Posté le 29-08-2008 à 16:16:02    

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é


---------------
Si la vérité est découverte par quelqu'un d'autre,elle perd toujours un peu d'attrait
Reply

Marsh Posté le 29-08-2008 à 16:16:02   

Reply

Marsh Posté le 29-08-2008 à 16:20:09    

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

Reply

Marsh Posté le 29-08-2008 à 16:23:35    

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.


Message édité par MagicBuzz le 29-08-2008 à 16:27:37
Reply

Marsh Posté le 29-08-2008 à 16:25:44    

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


Message édité par esox_ch le 29-08-2008 à 16:26:27

---------------
Si la vérité est découverte par quelqu'un d'autre,elle perd toujours un peu d'attrait
Reply

Marsh Posté le 29-08-2008 à 16:28:23    

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 :D


Message édité par MagicBuzz le 29-08-2008 à 16:29:07
Reply

Marsh Posté le 29-08-2008 à 16:32:08    

Comme d'habitude, ça dépend de ce que tu cherches [:spamafote]  
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 :o


---------------
Si la vérité est découverte par quelqu'un d'autre,elle perd toujours un peu d'attrait
Reply

Marsh Posté le 29-08-2008 à 16:33:42    

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 :o
 
1 licence à 100 € pour un vista family avec sql server express et t'as pas besoin d'un centime de plus... :spamafote: et au moins même la concierge elle peut le rallumer en cas de coupure de courant le week-end :o


Message édité par MagicBuzz le 29-08-2008 à 16:34:55
Reply

Marsh Posté le 29-08-2008 à 16:38:31    

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 :o


---------------
Si la vérité est découverte par quelqu'un d'autre,elle perd toujours un peu d'attrait
Reply

Marsh Posté le 29-08-2008 à 16:39:03    

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


Message édité par MagicBuzz le 29-08-2008 à 16:41:14
Reply

Marsh Posté le 29-08-2008 à 16:45:58    

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 :o
 
Mais bon de toutes façons là on s'éloigne du problème ..


---------------
Si la vérité est découverte par quelqu'un d'autre,elle perd toujours un peu d'attrait
Reply

Marsh Posté le 29-08-2008 à 21:53:18    

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.


---------------
Adrien
Reply

Marsh Posté le 30-08-2008 à 05:46:59    

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

Reply

Marsh Posté le 01-09-2008 à 11:46:55    

MagicBuzz a écrit :

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  :D


---------------
Photos Panoramiques Montagnes Haute Savoie
Reply

Marsh Posté le 03-09-2008 à 23:59:26    

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


---------------
NewsletTux - outil de mailing list en PHP MySQL
Reply

Marsh Posté le 04-09-2008 à 08:49:11    

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.

Reply

Marsh Posté le 04-09-2008 à 11:34:54    

yellu a écrit :

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  :D


---------------
Photos Panoramiques Montagnes Haute Savoie
Reply

Marsh Posté le 04-09-2008 à 11:42:54    

grosbin a écrit :

Les deux méthodes sont valables tout de meme, j'ai de meilleurs résultats avec la seconde, personnellement  :D


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

Reply

Marsh Posté le 04-09-2008 à 12:03:17    

en lancant un chrono


---------------
Photos Panoramiques Montagnes Haute Savoie
Reply

Marsh Posté le 04-09-2008 à 12:04:17    

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)


Message édité par yellu le 04-09-2008 à 12:05:20
Reply

Marsh Posté le 04-09-2008 à 12:54:17    

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 :D


---------------
Photos Panoramiques Montagnes Haute Savoie
Reply

Marsh Posté le 04-09-2008 à 14:11:38    

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

Reply

Marsh Posté le 04-09-2008 à 14:45:00    

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

Reply

Marsh Posté le 04-09-2008 à 15:37:58    

omega2 a écrit :

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 :D


Message édité par grosbin le 04-09-2008 à 15:38:43

---------------
Photos Panoramiques Montagnes Haute Savoie
Reply

Marsh Posté le 04-09-2008 à 15:51:23    

2 visiteurs par minutes (j'ai considéré qu'il y avait plusieurs heures sans visite dans la nuit) et la base est saturé? :o 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.

Reply

Marsh Posté le 04-09-2008 à 15:54:55    

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

Reply

Marsh Posté le 05-09-2008 à 13:52:22    

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.

Reply

Marsh Posté le 05-09-2008 à 18:41:17    

Toujours pas ... c'est pas grave

Reply

Marsh Posté le 08-09-2008 à 09:14:50    

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

Reply

Marsh Posté le 08-09-2008 à 20:57:43    

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


Message édité par grosbin le 08-09-2008 à 21:01:22

---------------
Photos Panoramiques Montagnes Haute Savoie
Reply

Marsh Posté le 09-09-2008 à 09:16:52    

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 :spamafote:
 
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 :spamafote:
 
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...

Reply

Marsh Posté le 09-09-2008 à 12:17:10    

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 )

Code :
  1. SELECT SQL_CACHE id,Reste,Terrain,Agrement FROM SpeMed WHERE id IN (1171,1157,1169,1215,1223) AND Reste>0 ORDER BY case id when 1171 then 1 when 1157 then 2 when 1169 then 3 when 1215 then 4 when 1223 then 5 end


 - 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 :D

 

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 ?


Message édité par grosbin le 09-09-2008 à 12:21:36

---------------
Photos Panoramiques Montagnes Haute Savoie
Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed