Rapidité Serveur : PhP-SQL
Fermé
azerty0
Messages postés
1274
Date d'inscription
samedi 27 octobre 2007
Statut
Membre
Dernière intervention
5 septembre 2013
-
4 févr. 2011 à 12:57
Utilisateur anonyme - 7 févr. 2011 à 08:37
Utilisateur anonyme - 7 févr. 2011 à 08:37
A voir également:
- Rapidité Serveur : PhP-SQL
- Test rapidité pc - Guide
- Changer serveur dns - Guide
- Serveur pop - Guide
- Serveur dns gratuit - Guide
- Serveur dns orange - Accueil - Guide box et connexion Internet
3 réponses
Utilisateur anonyme
Modifié par baladur13 le 4/02/2011 à 17:45
Modifié par baladur13 le 4/02/2011 à 17:45
Bonjour,
Avec MySQL, multiplier les requêtes ce n'est jamais très bon.
Je partirais déjà sur PostGreSQL qui tient mieux la route.
Je ferais quand même les calculs en PHP, plutôt qu'avec des triggers, mais dans le doute le plus simple c'est de faire un test de charge avec deux solutions simples mais lourdes.
MySQL reste quand même une base pas très optimisée, j'ai un site avec des volumes moyens dans la base, peu d'AJAX mais pas mal de requêtes avec jointures, au delà de 100 connexions par minute, MySQL tombe, et pourtant c'est un serveur dédié.
Donc moins MySQL en fait, mieux c'est.
Mais je suis hors sujet désolé, je me suis laissé emporter 8-)
Une requête ramenant beaucoup de champs c'est mieux que beaucoup de requêtes. Après pourquoi les calculs dans des triggers ?
J'aide pas beaucoup là...
Cordialement
Signature non conforme - Publicité supprimée Modération CCM
Avec MySQL, multiplier les requêtes ce n'est jamais très bon.
Je partirais déjà sur PostGreSQL qui tient mieux la route.
Je ferais quand même les calculs en PHP, plutôt qu'avec des triggers, mais dans le doute le plus simple c'est de faire un test de charge avec deux solutions simples mais lourdes.
MySQL reste quand même une base pas très optimisée, j'ai un site avec des volumes moyens dans la base, peu d'AJAX mais pas mal de requêtes avec jointures, au delà de 100 connexions par minute, MySQL tombe, et pourtant c'est un serveur dédié.
Donc moins MySQL en fait, mieux c'est.
Mais je suis hors sujet désolé, je me suis laissé emporter 8-)
Une requête ramenant beaucoup de champs c'est mieux que beaucoup de requêtes. Après pourquoi les calculs dans des triggers ?
J'aide pas beaucoup là...
Cordialement
Signature non conforme - Publicité supprimée Modération CCM
azerty0
Messages postés
1274
Date d'inscription
samedi 27 octobre 2007
Statut
Membre
Dernière intervention
5 septembre 2013
75
4 févr. 2011 à 16:40
4 févr. 2011 à 16:40
Bonjour,
Si vous m'aidez, mais je ne suis pas sur d'avoir tout saisis.
Par exemple : Imaginons, une table transactions et une table Utilisateurs.
Pour compter les transactions relatives à un utilisateur,
Vaut-il mieux :
- Un count réalisé sur la table transactions pour déterminer le nombre de transactions d'un utilisateur. (requête donc plutot lourde)
- Un champ nb_transactions dans utilisateurs mis à jour a chaque nouvelle instance dans la table transactions, imposant donc une requête beaucoup moins lourde.
Pour ce qui est des Triggers, c'était dans ce cas la :
Par exemple, imaginons un parrain et un filleul sur un site.
Lorsque le filleul réalise telle action, alors, on fait appel au trigger pour lui décerner tel ou tel avantage. Sinon, cela implique de faire des tests a chaque nouvelle action du filleul pour savoir si cela va provoquer l'action "Donner avantage à parrain.". Cela me parait beaucoup moins lourd en terme de requête, mais je ne sais pas si c'est conseillé d'utiliser les triggers.
Si vous m'aidez, mais je ne suis pas sur d'avoir tout saisis.
Par exemple : Imaginons, une table transactions et une table Utilisateurs.
Pour compter les transactions relatives à un utilisateur,
Vaut-il mieux :
- Un count réalisé sur la table transactions pour déterminer le nombre de transactions d'un utilisateur. (requête donc plutot lourde)
- Un champ nb_transactions dans utilisateurs mis à jour a chaque nouvelle instance dans la table transactions, imposant donc une requête beaucoup moins lourde.
Pour ce qui est des Triggers, c'était dans ce cas la :
Par exemple, imaginons un parrain et un filleul sur un site.
Lorsque le filleul réalise telle action, alors, on fait appel au trigger pour lui décerner tel ou tel avantage. Sinon, cela implique de faire des tests a chaque nouvelle action du filleul pour savoir si cela va provoquer l'action "Donner avantage à parrain.". Cela me parait beaucoup moins lourd en terme de requête, mais je ne sais pas si c'est conseillé d'utiliser les triggers.
Utilisateur anonyme
7 févr. 2011 à 08:37
7 févr. 2011 à 08:37
Bonjour,
Tout dépend.
Que fais-tu le plus souvent, afficher (compter) le nb de transaction ou ajouter des transactions.
Si c'est compter, utilise un champ compteur, si c'est ajouter et occasionnellement compter, utilise count(), tout est une question d'équilibre.
Pour les triggers, j'utilise les triggers pour assurer la cohésion logique de la base, tel champ dans une table implique tel et tel action dans une autre table, cela permet de manipuler la base sans passer par l'application en cas de pb sans ce faire des noeuds dans la tête sur l'intégrité de la base.
Si dans ton exemple la non mise en place des avantages du parrain ne mettent pas en danger la logique de ton système, fait le dans le code, pas avec des triggers.
Enfin c'est ma philosophie, surtout avec MySQL...
Tout dépend.
Que fais-tu le plus souvent, afficher (compter) le nb de transaction ou ajouter des transactions.
Si c'est compter, utilise un champ compteur, si c'est ajouter et occasionnellement compter, utilise count(), tout est une question d'équilibre.
Pour les triggers, j'utilise les triggers pour assurer la cohésion logique de la base, tel champ dans une table implique tel et tel action dans une autre table, cela permet de manipuler la base sans passer par l'application en cas de pb sans ce faire des noeuds dans la tête sur l'intégrité de la base.
Si dans ton exemple la non mise en place des avantages du parrain ne mettent pas en danger la logique de ton système, fait le dans le code, pas avec des triggers.
Enfin c'est ma philosophie, surtout avec MySQL...