Salut a tous !
 
Comme j'en avait marre d'avoir un code plein de mysql_connect() , de mysql_query() et de mysql_close() j'ai créé ces class PHP qui automatisent toutes les requetes SQL standard de type INSERT, SELECT, UPDATE et DELETE, ne vous attendez pas a du left JOIN ou des trucs tres complexes, elles gerent les conditions les recherches multicriteres, bien pratiques pour faire du ménage dans le code
 
J'ai mis un certain temps a la coder, la prochaine etape est un mode de déboguage avancé... Si elle peut vous servir , je la laisse a disposition
lib_SQL.php ( 14Ko )

l'archive est buggée chez moi

utilise winrar

 
Ou unrar

bref... J'espere qu'elle pourra vous servir, moi je ne me sert plus que d'elle !

Juste un truc, ton mysql_close ne sera jamais appelé.

exaact, si vous avez des suggestions ou des remarques je suis preneur, je mettrai les update dessus

avez vous des suggestions , des choses que je puisse ajouter ?

Moi perso, je n'aime pas trop utiliser la fonction die.
C'est bien pratique mais si par malheur il y a une erreur, la page est arretée net de charger.
 
Je prefere souvent utiliser le @ et faire mes propres traitement d'erreur.
 

oui, c'est prévu, je vais implémenter une gestion avancée des erreurs
 
Mon prochain projet est un editeur PHP interfacé Web

en fait je me questionnais sur l'intéret d'avoir une 'petite usine à gaz' comme ça, qui gère toutes les requêtes simplement en lui passant un tableau.
 
Parce qu'on est tous d'accord qu'il faut séparer le SQL de la logique métier, afin notamment de changer de base de données facilement. Mais là quand on va changer de base de donnés, je suis pas certain qu'il ne faudra modifier que ta lib_sql. Les tableaux que l'on passe en parametre à ces fonctions seront surement à revoir aussi. Donc tout sera à revoir quoiqu'il arrive si on change de base de données
 
Moi personnellement j'ai un singleton qui gère la connection à la base, fait les requetes (rien de bien sorcier, un cas selet et un cas modif base), gere les transactions (s'il y en a).
Et donc les requetes SQL elles-même sont dans une couche au-dessus, mais qui reste séparer de la logique métier. Donc si je change de base, j'ai mon singleton et la couche avec les requetes à changer.
Et je suis pas sur que ça fasse beaucoup plus de boulot.
 
Qu'en pensez vous ?

Djebel1> tout à fait d'accord avec toi, il faut séparer la couche metier du SQL.  
 
D'ailleur, il existe des outils très puissant qui permettent de faire cette séparation de manière quasi automatique : les ORM (object relationnal mapping)
Il y en a un qui me vient à l'esprit pour le php : Propel http://propel.phpdb.org/trac/ mais il en existe d'autres

fluminis> oui, on est d'accord, mais comment le mettre en oeuvre si on développe ses propres classes pour accéder à la base ?
Avec une classe gérant toutes les requetes possibles, et à laquelle on a plus qu'à balancer des paramètres (un peu comme ici), ou avec une couche supplémentaire dans laquelle on met les requetes SQL ?

Au lieu de réinventer la roue, je pense que tu devrais rechercher "object relational mapping" sur la Wikipedia US, et lire le premier résultat se présentant.

Perso, je viens de développer un outils d'ORM en C#, je ne tiens pas à dire que mon architecture est la meilleure loin de là, mais voila comment j'ai fait. L'architecture est la suivante :
 
j'ai une couche metier (classes Article, Magasin)
ces classes derivent de ma classe DataObject.
 
Chaque modification d'un champ de Article averti DataObject que le champs est changé (facilité en C# avec les setters/getters)
Ensuite lorsque je fais monArticle.Save();
DataObject entre en jeux et construit les requetes, non pas en SQL mais en utilisant un objet SqlEngine. C'est cet objet qui sera dérivé en MySqlEngine ou PostgresSqlEngine...
 
SqlEngine contient des fonctions comme : addField pour ajouter un champ dans la requete, addCondition pour ajouter une condition...
 
Une autre solution est comme tu l'évoques, celle d'écrire en dur les requetes SQL dans les objet. Mais si tu changes de base de données, il va te falloir réécrire tout ou partie de tes requetes SQL et donc aller toucher a tous tes objets.
 
A voir laquelle des deux solutions te convient le mieux.

 
De ce que j'ai vu, j'ai l'impression que tu suis la regle du : pourquoi faire simple quand on peut faire compliquer?
Faire une classe gerer la connexion les recordset est une bien meilleure idée que de faire qq chose de relativement figé. Tout depend de la complexité de tes requetes. Mais ce devient tres vite dur d'utiliser tes classes.

ha oui ton système a l'air très sympa. Mais j'ai un peu de mal avec les DataObject.  
Sont-ils vraiment si portables ? Si tu veux changer de base pour une qui n'est pas supportée par le DataObject, tu ne dois vraiment retoucher QUE cet objet ? Puisque comme tu dis toi-même, ta couche métier dérive de ta couche DataObject.
 
Disons que moi j'ai une couche accès à mysql, et une couche requête mysql en dur. Si je change de base de données, je sais que je n'aurai que ces deux couches à réécrire. Qu'en est-il avec le DataObject, tu ne devras retoucher que lui ?

d'ou dans le titre automatisations des requetes SQL standard !
 
je cherche pas a faire un truc complexe, je l'ai developpée en fonction de mes besoins, quand j'aurais besoin de plus je ferais plus c'est tout !
Quant a pourquoi faire simple quand on peut faire compliqué, c'est juste que je préfere avoir quelques declarations plutot que toutes les requetes ( mysql_connect(), mysql_select_db(), mysql_query(), mysql_fetcharray/object() , mysql_close() )

pour simplifier, dans ma class DataObject, il n'y a pas une ligne de sql :
 
Y a des trucs du genre :
   SqlEngine engine = Database->GetSqlEngine('UPDATE');
 
   engine.AddField('nom_article', 'valeur');
   ...
   engine.AddCondition('id_article', 'mon id');
   engine.Execute();
 
bien sur, il y a de la généricité, pour que DataObject connaisse la liste de tout les champs de l'objet.

mouais bon vais devoir reprendre ma couche SQL moi quoi  

vous auriez quelques liens sympatoches et pas compliqués pour commencer avec les DAO, expliquer leur fonctionnement et comment les construire ?

Les liens que j'ai sont pour le language C#, j'en ai pas sous la main pour le PHP dsl, mais la théorie est somme toute la même
 
Une très bonne page (en anglais) :
http://www.codeproject.com/dotnet/CodeGenResource.asp
 
Et celle là sur la théorie des ORM :
Mapping Objects to Relational Databases: O/R Mapping In Detail :
http://www.agiledata.org/essays/mappingObjects.html
 
Edit: en php, comme indiqué plus haut : Propel http://propel.phpdb.org/trac/
regarde le, tu n'as pas forcement besoin de réinventer la roue.

super merci je vais m'y coller

je vais regarder aussi