6
votes

Quoi de plus efficace et pourquoi: une connexion DB par page ou une connexion DB par fonction?

Je travaille sur un site web qui est très mysql db conduit. Donc, j'ai beaucoup de questions à suivre.

dans Ce sujet tout le monde recommande de se connecter à la DB en haut de la page et de se déconnecter au bas de la page.

Je me demande ce qui est plus efficace, ou de manière générale des meilleures pratiques: Fabriquez une seule connexion à la base de données par page, ou connectez-vous uniquement si nécessaire? (ou n'y a-t-il pas de réponse générale, et cela dépend?)

En outre, je cherche à trouver pourquoi est cette meilleure pratique, de quel point de vue regardez-vous le scénario (par exemple, la sécurité, la vitesse, ... Je ne sais pas quoi d'autre Les connexions DB peuvent affecter ?!)

Je crois que cette question a été posée avant ici - mais pas pour PHP dans spécifique, et donc je n'ai pas trouvé cela utile.

Ma pratique actuelle a été de se connecter à la DB par mysqli pour chaque fonction que j'écris et déconnecte à la fin de la fonction, car elle me semblait plus propre. De cette façon, si une page n'appelle pas à une fonction qui nécessite un accès à la DB, il n'y aura jamais de connexion ouverte. Cependant, il peut arriver qu'il peut y avoir jusqu'à environ 10 connexions par chargement, en fonction de l'utilisateur sur le site. Je pensais que cela pourrait être une distribution juste des ressources. Si je l'ai compris correctement, il ne peut toujours pas être ouvert une connexion 1 dB ouverte. Par conséquent, je suppose que toutes les demandes de connexion seront en file d'attente. Donc, si un utilisateur a des requêtes multiples, longues et compliquées, cet utilisateur ne tiendrait pas tout le trafic, car entre chacune des requêtes, d'autres requêtes courtes pourraient être traitées. Mais c'est juste que je fais des affaires, je ne sais pas si cela fonctionnerait vraiment de cette façon ...: D

Aussi, je sais que beaucoup de développeurs autour d'ici aiment utiliser po . J'ai choisi d'utiliser mysqli lorsque j'ai commencé à développer, et je n'ai aucun projet de commutation. J'espère que ma question peut être applicable aux deux bibliothèques.

merci: -)


0 commentaires

3 Réponses :


8
votes

Les connexions de base de données sont coûteuses à créer. C'est pourquoi la plupart des gens recommandent de créer la connexion une fois et de la réutiliser jusqu'à ce que l'exécution soit arrêtée, voire plus longtemps si la bibliothèque client de base de données le permet.

Par exemple, PDO permet de créer des connexions persistantes, ce qui augmente les performances, car la connexion serait réutilisée pour servir plusieurs demandes d'affilée. De http://php.net/manual/fr/pdo.connections.php:

De nombreuses applications Web bénéficieront d'une connexion persistante aux serveurs de base de données. Les connexions persistantes ne sont pas fermées à la fin du script, mais sont en cache et réutilisées lorsqu'un autre script demande une connexion à l'aide des mêmes informations d'identification. Le cache de connexion persistant vous permet d'éviter les frais généraux d'établir une nouvelle connexion à chaque fois qu'un script doit parler à une base de données, ce qui permet une application Web plus rapide.


2 commentaires

Vous dites "Les connexions db sont chères créer" ... Je vais prendre votre déclaration pour un fait vrai et commencer à ouvrir une connexion par page ... J'apprécierais certaines informations supplémentaires sur ce que le rend "cher".


Vous pouvez demander cela comme une question distincte pour obtenir une contribution de plus de personnes. Les sessions de base de données sont des choses compliquées: sur le client, la connexion réseau, l'état SQL Parser, et sur le serveur, il y a des tampons de toutes sortes. Ils doivent tous être créés et initialisés pour chaque session et libérés après la session. Tout cela prend un temps non trivial, bien que évidemment plus pour certaines bases de données que d'autres.



2
votes

Une connexion DB par page ou une connexion DB par fonction?

un par page

Pourquoi cette meilleure pratique,

vitesse et sens commun

Si je l'ai compris correctement, il ne peut toujours pas être ouvert une connexion 1 dB ouverte.

faux. La seule limite peut être réglée au côté DB. Et il y a toujours une piscine.

Fabriquez une seule connexion de base de données par page ou connectez-vous uniquement si nécessaire?

Qu'est-ce qui vous arrête de connecter une fois mais seulement si nécessaire ? FAITES VOTRE FONCTION DB AutoConnect s'il n'y a pas de connexion ouverte et réutilisez-la si elle existe. Bien que je ne trouve pas cela en vaut le désordre pour le site "TRÈS MYSQL DB Driven" ".


0 commentaires

5
votes

Je suggérerais que vous envisagez d'utiliser un motif d'usine de connexion. Cela vous permettra de n'appeler que l'usine dans des fonctions qui en ont besoin (en évitant la surcharge d'une connexion si une connexion n'est jamais nécessaire) tout en vous permettant de réutiliser une connexion si vous avez déjà effectué une connexion (en évitant la surcharge de construction répétée et Déconstruire les connexions).

Peut-être un ConnectifFactory.php inclus dans vos pages ou disponible via Yer Charger comme celui-ci. xxx

}

vous pouvez Ensuite, utilisez-le plus tard dans une fonction: xxx

}

Ceci garantit que vous n'abumusez jamais surcharge si vous n'utilisez pas de connexion du tout, et si Vous faites, vous pouvez ensuite exploiter la connexion.

devzone.zend.com dit: "Les connexions ouvertes (et les ressources similaires) sont automatiquement détruites à la fin de l'exécution de script."

donc vous ne faites pas Il faut expliquer explicitement la connexion. Cependant, il y a peut-être des moments où il est souhaitable de le faire pour des raisons de performance. Cela dépendra du contexte dans lequel vous rencontrez et vous devrez équilibrer vous-même lorsque vous regardez le contexte.

Vous pourriez également regarder le similaire global ou singleton pour la connexion de base de données?

Remarque: Je n'ai pas testé aucun de ce code , il est censé être un exemple de travail éventuellement. ; -)


0 commentaires