[Conception] quand ouvrir/fermer la connexion SQL ?

Bonjour,

J'emploie une classe PHP qui manipule PDO et j'effectue de nombreuses ouvertures (et fermetures) de connexions SQL, chaque ouverture/fermeture est effectuée pour un certain nombre de requêtes SQL plus ou moins liée à un même traitement.
Aujourd'hui j'ai un doute vis-à-vis de la charge imposée par ces ouvertures/fermetures SQL et j'aimerais savoir quelle est selon vous la meilleure méthode à employer lorsqu'on est dans un environnement de POO (chaque connexion SQL étant instanciée par un objet).

• Solution 1 : Une seule ouverture/fermeture SQL par page Web (ouverture au début du script, fermeture à la fin)

• Solution 2 : Une ouverture/fermeture SQL par groupe de requête (j'ouvre ma connexion SQL, j'effectue mes requêtes puis je ferme ma connexion etc...)

• Solution 3 : Une ouverture/fermeture SQL par requête

Aujourd'hui j'emploie la solution 2 et j'ai déjà employé les autres solutions. Je vois des inconvénients pour chacune des méthodes qui sont les suivants, corrigez-moi si je me trompe :

• Inconvénient Solution 1 : Si je souhaite accéder à plusieurs bases de données sur un même script, mes connexions SQL peuvent donc se chevaucher faisant que l'une des connexions SQL n'est pas forcément utile à un instant T.

• Inconvénient Solution 2 : Il faut toujours s'assurer de la fermeture des connexions SQL après chaque traitements groupés.

• Inconvénient Solution 3 : Sur un site "très" dynamique ayant de nombreuses requêtes, autant d'ouverture et de fermeture est probablement "lourd".

J'utilise une classe singleton pour un de mes objets et je n'ai pas encore l'intention de l'employer pour les connexions SQL. Bien qu'il y a un avantage certain à utiliser une singleton je préfère pour le moment m'assurer des ouvertures et fermetures moi même (c'est plus propre dans mes logs).

Si vous voyez une ou n autres solutions...
Je cherche une optimisation (cf post sur les optimisations PHP&SGBD)

Merci

Bonjour,

pour ma part j'ouvre toujours ma connexion au démarrage du script, car j'ai généralement toujours au moins une requête à exécuter. C'est me semble plus rapide et plus simple à gérer.

Je ne vois que des points négatifs : plus de code donc plus de lourdeur.

Je suis plutôt d'accord avec toi bien que j'ai perdu cette habitude d'ouvrir ma connexion au début de mes scripts. Surement depuis quelques projets multi-bases et contraintes rencontrées. Je ne m'en souviens plus...

Merci de ton avis

Salut

A mon avis, ton problème il est là :

Citation:

---

Solution 2 : Une ouverture/fermeture SQL par groupe de requête (j'ouvre ma connexion SQL, j'effectue mes requêtes puis je ferme ma connexion etc...)

---

Puisque tu utilises la poo, pourquoi tu ne fais pas un singleton.... Une connexion (ouverture et fermeture) par page, pas plus. Après si tu as besoin d'avoir plusieurs connections, tu rajoutes un manager de connexion qui te permet d'enregistrer des dsn et de switcher facilement au cours du code sans pour autant multiplier les connections.

A la lecture de la suite du poste....
A un moment faut arrêter de vouloir tout optimiser, on finit par faire l'inverse et pourrir les performances pour des raisons plus ou moins louables..
En bref, avoir deux (3, 4 5 6 5 ou même 7) connexions à une base de données sur le même thread PHP ne va pas le tuer et ne va pas le ralentir.
Le point négatif dans ce cas précis, c'est en mode web, car une requête web utilise alors deux (3, 4 ect) slots sql..
Ce qui surcharge le serveur sql rapidement.

a plus

Je parle de la singleton dans mon POST, il suffit de lire :P

En fait j'utilise une singleton (accès DB) pour certains projets (du "gros œuvre" on va dire). Ce n'est pas vraiment de l'optimisation que je cherche, plutôt une habitude de fonctionnement qui me plaise bien et qui satisfasse au mieux les services Web.

(C'est pas un pb pour moi de changer le gestionnaire DB de mes projets tout est en objet...)

a+

Et bien moi, dans la plus part de mes projets, j'ouvre une connection par script. Je trouve que cela facilite beaucoup l'utilisation des requêtes.