Hello,
 
Je fais du php à mes heures perdues
Mais voilà : depuis des années que j'en fais, je me suis toujours dis que je me déveloperais une petite classe pour simplifier le travail avec mysql.
Je me suis lancé !
 
J'ai donc créé une classe à inclure, comportant les fonctions utiles à la vie du dév. php/mysql.
 
Ma question est la suivante : Quand je fais un select, quelle philosophie adopter pour récuperer les lignes de résultats ?
 
1/ une fonction fetchObject() qui ferais un simple return mysql_fetch_object
2/ une fonction qui retournerais un tableau (d'objet ? ca serais plus simple..)
3/ autre solution ?
 
Au niveau des perfs je pense qu'il y a une certaine différence.. Mais je cherche aussi à simplifier le traitement des requetes..
Merci de vos suggestions !!

2/ va bouffer un paquet de ram , mais va etre plus facile a manipuler
 
perso ,je ferai les deux methodes ( genre fetchObject et fetchAllObject )  et je laisserai le choix à l'utilisateur  
a savoir qu'il existe une classe similaire dans le package PEAR ( DB )

En fait, pour les select, je pense que je vais faire ceci
return mysql_fetch_assoc($this->results);
 
L'utilisation donnera kkchose comme :
$cnx = new simpleMysql(...);
$objArray = $cnx->select("select * from machin" );

(j'ai l'impression d'etre super pas clair)...

flo850 -> ok, recu
merci !

Zend fait un tableau de tableau pour ça ce que je trouves couillon vu la place mémoire que ca peut prendre. J'aurais vraiment préféré qu'ils fassent juste un tableau en laissant le développeur changer de ligne de donnée quand il en a besoin. Ca éviterait également de perdre du temps processeur en recopiant tous les éléments.

Tu peux effectivement construire ta classe en fonction de ce que vont te retourner tes requêtes SQL.
 
L'idée ici ça serait de récupérer tes résultats dans des variables membres qui vont bien :
 
- une variable simple pour un résultat unique ;
- un vecteur (1D) pour tout ou partie d'un enregistrement unique ;
- un tableau de vecteurs (matrice 2D donc) pour tout ou partie de plusieurs enregistrements.
 
Après il faut gérer ces différentes "structures" contenant tes résultats SQL afin de savoir à quoi chaque donnée correspond (pour quel enregistrement ? pour quel attribut de ta table ?). Tu utilises pour ça des compteurs d'une part (pour ordonner tes enregistrements), et des vecteurs (qu'on va nommer Vattribut ici) contenant les noms de tous les attributs (de la table) impliqués dans la requête.
Ainsi, par exemple, tu utiliseras pour un vecteur résultat (N attributs d'1 unique enregistrement) un tableau associatif + un tableau Vattribut,
chaque clé du tableau associatif étant une valeur de Vattribut, et chaque valeur de ce même tableau associatif un résultat unitaire de la requête.
 
Je ne sais pas si je m'exprime clairement, mais en gros en entrée dans l'instance de ta classe tu lui files la requête SQL, puis tu lui demandes de se taper le parsage (pour identifier et conserver les attributs en jeu), le comptage (on ne peut pas prévoir ça juste avec la requête), puis le découpage et la répartition des résultats dans les variables membres qui vont bien.
 
Je réfléchis au truc en même temps que j'écris, d'où la possibilité de grosses conneries ou autres approximations...       En tout cas c'est un modèle simpliste d'une façon de traiter une requête SQL, et ça ne marcherait comme ça que pour du SELECT assez basique (typiquement SELECT... FROM... [WHERE...]), même si c'est ce qui s'emploie beaucoup concrètement... Bref, après il est nécessaire d'affiner et de compléter ce modèle en gérant également le traitement de requêtes à la syntaxe plus complexe.
 
Cependant, d'un simple point de vue pragmatique je doute de l'utilité (et de la performance, même si c'est pas trop la mort) d'un tel montage en php. Ca me paraît intéressant sur le plan théorique (si ya des fans de théorie du langage, ça devrait pas leur poser de problème de te formaliser tout ça, en beaucoup mieux certes^^') mais j'ai bien peur que ça s'arrête là.
Sinon ya aussi la solution, comme tu le proposes, d'encapsuler des fonctions php pour affiner/adapter un peu le paramétrage à ta sauce, mais encore une fois je suis pas sûr de la pertinence du truc... En tout cas ça irait très vite à mettre en oeuvre ;P