+ Répondre à la discussion
Page 19 sur 19 PremièrePremière ... 91516171819
Affichage des résultats 361 à 369 sur 369
  1. #361
    Membre éprouvé Avatar de tse_jc
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2010
    Messages
    251
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Haut Rhin (Alsace)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : août 2010
    Messages : 251
    Points : 415
    Points
    415

    Par défaut

    Je rajoute un lien discuté très recemment qui concerne également ce topic
    http://www.developpez.net/forums/d12...njections-sql/

    ++
    _______________________________________
    POO PHP+Ajax en MVC avec PDO et Bases de données épaisses : What else?

  2. #362
    Invité régulier
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    juin 2013
    Messages
    10
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Maroc

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juin 2013
    Messages : 10
    Points : 8
    Points
    8

    Par défaut

    Un petit ajout concernant l'optimisation des scripts php.
    Au lieu d'utiliser la fonction in_array il faudrait mieux utiliser isset(tab[index]) cvd rechercher sur l'index au lieu de la valeur.

  3. #363
    Expert Confirmé Sénior
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    juillet 2004
    Messages
    3 229
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : juillet 2004
    Messages : 3 229
    Points : 6 948
    Points
    6 948

    Par défaut

    Bonjour,

    in_array n'a pas du tout la même sémantique.

    in_array ça revient à faire
    Code php :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    function chercher($valeur) {
      $trouve = false;
      for($index=0; $index < $tab.length(); $index++) {
        if($tab[$index] == $valeur) {
          $trouve = true;
        }
      }
      return $trouve;
    }
     
    cherche('valeur cherchée');

    Alors que isset($tab[$index]) ne vérifie pas que 'valeur cherchée' est dans le tableau, mais simplement qu'il existe une entrée dont on ne connait pas la valeur à l'index dans le tableau.

    On peut donc toujours utiliser une boucle PHP pour chercher dans un tableau. Mais ce sera toujours moins optimal que d'utiliser une fonction native C++ compilée dans le noyau.
    A+JYT

  4. #364
    Invité régulier
    Inscrit en
    mai 2013
    Messages
    12
    Détails du profil
    Informations forums :
    Inscription : mai 2013
    Messages : 12
    Points : 7
    Points
    7

    Par défaut

    Bonjour tout le monde,

    Je me poses deux questions relatives à l'optimisation de PHP/MySQL:

    1) hachesse a dit ceci :

    Citation Envoyé par hachesse Voir le message
    Ouvir 1 seule connection à la base de donnée et la fermée à la fin de la page, preferer le connect au pconnect
    C'est pas mieux de se connecter/déconnecter pour chaque requête une fois qu'on a récupérer les valeurs pour peu que les requêtes soient espacées les unes des autres ?

    2) Lorsqu'on fait une boucle, vaut-il mieux stocker en variable pour tout afficher une fois la boucle terminée ou afficher au fur à mesure ?

    Exemple :

    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    // Tout afficher d'un seul coup
    while ($row = @mysql_fetch_assoc($sql)) {
         $var .=$row[col1];
    }
    echo $var;
     
    // Afficher au fur et à mesure
    while ($row = @mysql_fetch_assoc($sql)) {
         echo $row[col1];
    }
    Merci beaucoup pour ce sujet très intéressant et pour toutes réponses à mes questions !

  5. #365
    Membre Expert Avatar de papajoker
    Homme Profil pro
    Développeur Web
    Inscrit en
    septembre 2013
    Messages
    1 002
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nièvre (Bourgogne)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : septembre 2013
    Messages : 1 002
    Points : 1 965
    Points
    1 965

    Par défaut

    Citation Envoyé par King Bradley Voir le message
    C'est pas mieux de se connecter/déconnecter pour chaque requête une fois qu'on a récupérer les valeurs pour peu que les requêtes soient espacées les unes des autres ?
    Une connexion prend plus de temps qu'une simple requete, donc avec 3 SELECT, tu vas multiplier ton temps par 4(ou plus) sur une page

    pour peu que les requêtes soient espacées les unes des autres
    Il faut combien de temps à php pour exécuter 50 lignes de code entre tes requêtes ? php est rapide
    Et si tu as 1000 personnes de connectées sur ton site le serveur se prend 3000 connexions en 2 secondes ! et même si tu espaces tes requêtes

    Citation Envoyé par King Bradley Voir le message
    2) Lorsqu'on fait une boucle, vaut-il mieux stocker en variable pour tout afficher une fois la boucle terminée ou afficher au fur à mesure ?
    La vitesse est la même, simplement dans un cas tu consommes de la mémoire, alors que dans l'autre c'est négligeable. On ne choisit la structure gloutonne, voire dangereuse, uniquement si elle est nécessaire.
    $moi= ( !== ) ? : ;

  6. #366
    Invité régulier
    Inscrit en
    mai 2013
    Messages
    12
    Détails du profil
    Informations forums :
    Inscription : mai 2013
    Messages : 12
    Points : 7
    Points
    7

    Par défaut

    Merci beaucoup pour ces réponses claires et précises

  7. #367
    Expert Confirmé Sénior
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    juillet 2004
    Messages
    3 229
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : juillet 2004
    Messages : 3 229
    Points : 6 948
    Points
    6 948

    Par défaut

    Citation Envoyé par King Bradley Voir le message
    Bonjour tout le monde,

    Je me poses deux questions relatives à l'optimisation de PHP/MySQL:

    1) hachesse a dit ceci :



    C'est pas mieux de se connecter/déconnecter pour chaque requête une fois qu'on a récupérer les valeurs pour peu que les requêtes soient espacées les unes des autres ?

    2) Lorsqu'on fait une boucle, vaut-il mieux stocker en variable pour tout afficher une fois la boucle terminée ou afficher au fur à mesure ?

    Exemple :

    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    // Tout afficher d'un seul coup
    while ($row = @mysql_fetch_assoc($sql)) {
         $var .=$row[col1];
    }
    echo $var;
     
    // Afficher au fur et à mesure
    while ($row = @mysql_fetch_assoc($sql)) {
         echo $row[col1];
    }
    Merci beaucoup pour ce sujet très intéressant et pour toutes réponses à mes questions !
    1) attention pconnect c'est grâce à lui qu'on a sur les site avec MYSQL derrière des "Too many connections in ..." en effet le pconnect ne ferme pas les connexions mais normalement les restitues pour la réutiliser. il s'agit d'un pool de connexions mais on ne maîtrise pas le nombre côté client d'où des pb.

    2) moins on ouvre et ferme les connection mieux c'est.

    3) c'est tout le problèmes des pattern en couche. en théorie la couche présentation ne doit pas avoir accès à la couche métier (uniquement au contrôleur) le contrôleur ne devrait donner que des valeur à la couche présentation et pas d'objet métier.
    l'objet métier lui-même ne doit pas accéder à la persistance mais passer par le service d'accès au donnée DAO. le DAO ne doit pas donner d'objet de persistance à la couche métier.
    voilà pour la théorie. il en résulte que lorsque ta requête à remonté les données elle doit donner ces données à l'objet métier. mais ne doit pas lui fournir les élément de persistance. donc normalement l'objet métier ne peut voir le resultset.
    il en résulte que la seule solution est de placer les données en mémoire hors du resultset.
    c'est pourquoi souvent on vois dans ces archies le DAO parcourir le resultset pour alimenter un objet métier.
    mais lorsque le contrôleur récupère à sont tour l'objet métier il ne doit pas le donner à la couche présentation. là encore on n'a pas le choix si on respecte la théorie les données sont sortie de l'objet métier pour être placé dans la vue.

    tout ceci est consommateur d'espace et de temps. les frameworks s’arrangent plus ou moins avec la théorie.
    une solution fréquente consiste à créer un dataobjet (objet sans méthode juste des membres). le DAO extrait les data du resultset et le mets dans le dataobjet. il donne ensuite une référence à l'objet métier. celui-ci garde la référence et l'encapsule. on vois alors les membre comme s'il était ceux de l'objet métier. le contrôleur à sont tour passe cette référence à la vue. la vue peux donc accéder au data mais pas manipuler les méthodes métier. l'honneur est sauf.
    enfin presque car si la vue change une valeur l'objet métier et modifié. en effet la vue possède la même référence que l'objet métier sur le dataobjet. ce n'est donc pas parfait.

    l'optimal en terme de temps et d'espace est de donner directement le resultset à la vue. en effet on ne lit le contenu du résultset que lorsqu'on l'utilise réellement. mais du coup plus e couche plus de métier plus de contrôle.

    enfin in existe bien des optimisations intermédiaire pour ce problème. et le mieux est de connaitre les patterns existant et de comprendre leurs objectifs, leurs contraintes, leur champs d'applications, pour faire le bon choix en toute connaissances.

    A+JYT

  8. #368
    Expert Confirmé Sénior

    Homme Profil pro
    Développeur Web
    Inscrit en
    septembre 2010
    Messages
    2 700
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : septembre 2010
    Messages : 2 700
    Points : 4 617
    Points
    4 617

    Par défaut

    1/ Donc concernant l'ouverture/fermeture des connections on peut être affirmatif, et retenir que "moins on ouvre et ferme la connection et mieux c'est" car ce processus prend un temps non négligeable.

    2/ Par contre concernant le fait d'enregistrer le contenu du résultat dans une variable (souvent un tableau), c'est plus discutable. Outre le fait que cela permet de libérer plus vite la ressource de la requête, on le fait aussi très souvent pour des pb d'organisation de code comme indiqué par sekaijin. Sur le principe c'est très optimisé côté serveur bdd mais évidemment moins côté php qui doit passer par la création d'un tableau et donc consommer du temps et de la mémoire. Donc suivant les configurations de code mais aussi et surtout suivant la grandeur du tableau, on pourra choisir d'afficher directement la ressource plutôt que de passer par un tableau ou un objet intermédiaire. Mais à la différence de papajoker (si j'ai bien compris sa réponse) et notamment pour les raisons indiquées par sekaijin, je dirai que c'est plutôt assez rare et qu'on à tendance à privilégier aujourd'hui la structure "gloutonne" côté php. Enfin bon tu vois que les réponses peuvent varier suivant les critères et le code que l'on considère et l'on ne peut pas être aussi catégorique que pour ta première question.
    - Réalisations
    - Interface graphique : génération en javascript d'objets défilants, texte et/ou images, mode horizontal ou vertical.

  9. #369
    Invité régulier
    Inscrit en
    mai 2013
    Messages
    12
    Détails du profil
    Informations forums :
    Inscription : mai 2013
    Messages : 12
    Points : 7
    Points
    7

    Par défaut

    Oui, je vois ça ^^

    Merci à vous trois pour ces réponses !

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •