Class PHP5 de gestion de requetes SQL simples - PHP - Programmation
Marsh Posté le 28-04-2006 à 00:21:50
J'ai une suggestion.
Tu nous présente un cas d'utilisation pour appater le client, car un pavé comme ca ca me donne pas envie de le lire pour savoir comment l'utiliser. Pis les commentaires c'est bien, tant que ca fait pas "mis la juste pour le principe de mettre une ligne de commentaire par ligne de code"...
Marsh Posté le 28-04-2006 à 00:35:14
Uhm, ton objet Mysql_select, il ne peut faire un select que sur une table ? Mes jointures, je les fais comment ?
Ta fonction QueryType($Query), je la pige pas, tu fais un objet mysql_select pour les selects, un objet mysql_update pour des updates (je trouve ça bizare, mais bon...), donc tu connais le type de requête via l'objet, et tu refais une fonction pour connaitre le type de requête que tu fais dès fois que tu es pas sur
et en pratique, tout ça, ça marche facilement ?
Marsh Posté le 28-04-2006 à 00:42:40
Mackila a écrit : J'ai une suggestion. |
C'est vrai que je devrais mettre un exemple, quant aux commentaires moi je preferes les mettre en littéral plutot qu'en technique comme on le ferait en Java ou en C#, je trouve ca plus clair. Et un commentaire par ligne permet de bien expliquer le fonctionnement voila tout
J'ai edité
Marsh Posté le 28-04-2006 à 00:45:33
the_bigboo a écrit : C'est vrai que je devrais mettre un exemple, quant aux commentaires moi je preferes les mettre en littéral plutot qu'en technique comme on le ferait en Java ou en C#, je trouve ca plus clair. Et un commentaire par ligne permet de bien expliquer le fonctionnement voila tout |
ouais mais bon, des commentaires comme ça
Code :
|
On peut s'en passer je pense
Marsh Posté le 28-04-2006 à 00:46:37
zapan666 a écrit : Uhm, ton objet Mysql_select, il ne peut faire un select que sur une table ? Mes jointures, je les fais comment ? |
Les jointures, je n'en utilises pas vraiment , la plupart du temps je n'en ai pas besoin mais je pense effectivement implémenter les jointures sous peu, comme dit, c'est a l'heure actuelle concu pour des requetes simple
Comcernant la procédure queryType elle concerne les valeur de retour des procédures makes des objets
Par exemple sir tu veux avoir un nombre de résultat en retour, pour un SELECt tu utiliseras mysql_num_rows(), mais pour un UPDATE, ca sera mysql_affected_rows() Ca sert pour le switch
Marsh Posté le 28-04-2006 à 00:47:36
zapan666 a écrit : ouais mais bon, des commentaires comme ça
|
oui, mais c'est une habitude, on a tous ses tics Et je me fais pas d'idée , si ca vous gene, il suffit de tater de la touche suppr
Marsh Posté le 28-04-2006 à 00:49:11
the_bigboo a écrit : Les jointures, je n'en utilises pas vraiment , la plupart du temps je n'en ai pas besoin mais je pense effectivement implémenter les jointures sous peu, comme dit, c'est a l'heure actuelle concu pour des requetes simple |
et pourquoi dans Mysql, tu ne mets pas la fonction Execute en abstrait, et tu la défini dans chaqun de tes objets ?
Et quand on mets un switch, dans du code objet, la plupart du temps, c'est pas normal.
Marsh Posté le 28-04-2006 à 00:50:56
zapan666 a écrit : et pourquoi dans Mysql, tu ne mets pas la fonction Execute en abstrait, et tu la défini dans chaqun de tes objets ? |
parce que ce qui me gene c'est que j'utilise $this dans chacun des objets et que je ne connais pas le comporteme,t que ca aurait si je la mettai en abstrait, si tu préfere je sais pas si elle va utiliser la classe parente ou le classe enfant , c'est p'tetre con mais bon...
Si tu me renseigne, je serai ravi de coriger
En quoi n'est-ce pas normal d'utiliser un switch dans du code objet
Marsh Posté le 28-04-2006 à 01:02:39
the_bigboo a écrit : parce que ce qui me gene c'est que j'utilise $this dans chacun des objets et que je ne connais pas le comporteme,t que ca aurait si je la mettai en abstrait, si tu préfere je sais pas si elle va utiliser la classe parente ou le classe enfant , c'est p'tetre con mais bon... |
Code :
|
the_bigboo a écrit : |
Parce que
Bon, j'ai pas trouvé de la doc intéressante, mais normalement, tu peux t'en passer, genre sur ton code.
http://www.parashift.com/c++-faq-l [...] n-cpp.html
Marsh Posté le 28-04-2006 à 03:58:28
euh, on peut grave pas utiliser les fonctionnalités d'une bdd avec ton truc là.
Et tu te prends bien la tête, par exemple il suffit d'une fonction balançant les requetes à la base, pas la peine de faire dix milles fonctions et conditions en fonction des requetes.
Et donc là, comment je me connecte à plusieurs bdd, ou avec plusieurs comptes, comment je fais mes jointures, mes transactions, mes appels de procédure stockée ?
T'as voulu te faire un truc trop défini, donc pas du tout évolutif, et limité forcément à tes connaissances SQL puisque tu essayes de prévoir chaque cas.
Critiquer c'est facile, donc demain au taf je mettrai la mienne, histoire de me faire poutrer (enfin je la pense bien plus fonctionnelle que la tienne malgré tout )
Marsh Posté le 28-04-2006 à 08:38:54
Djebel1 a écrit : euh, on peut grave pas utiliser les fonctionnalités d'une bdd avec ton truc là. |
Il n'est pas question de se faire poutrer ou quoi Mais de partager des points de vue
personnelemment je l'ai faite en fonction de mes besoins , je me débrouille toujours pour ne pas avoir besoin de jointure meme si dans certains ca ce serait en effet assez pratique
D'autre part, les procédures stockées ne m'intéressent pas pour le moment car les applications qui s'executent au niveau PHP n'ont a l'heure actuelle aucun besoin d'etre déporté sur la base.
Effectivement ce serait cool que tu me montre comment tu as fait tes jointures
Marsh Posté le 28-04-2006 à 09:28:58
the_bigboo a écrit : Il n'est pas question de se faire poutrer ou quoi Mais de partager des points de vue |
Le truc que je trouve dommange c'est que des librairies d'accès à des bases de données pour le coup il en existe déjà plein en php alors pourquoi en refaire une
Prenons par exemple adodb(il en existe plein d'autres mais c'est celle que j'ai l'habitude d'utiliser), elle permet de faire tout ton bouzin sauf qu'en plus (entre autre):
Alors autant on peut critiquer les templates(cf vieille conversation), autant là j'aurais du mal à comprendre les avantages de le "refaire" à la main.
Marsh Posté le 28-04-2006 à 09:45:29
anapajari a écrit : Le truc que je trouve dommange c'est que des librairies d'accès à des bases de données pour le coup il en existe déjà plein en php alors pourquoi en refaire une |
Parce que bien que performantes elles sont souvent assez lourdes d'execution et leur utilisation toujours pas tres bien expliquée, j'ai survollé adodb comme tu l'indiquait, mais ya aucune doc d'utilisation ou je suis aveugle
Marsh Posté le 28-04-2006 à 09:56:58
the_bigboo a écrit : Parce que bien que performantes elles sont souvent assez lourdes d'execution |
Pourrais-tu expliquer ton propos? Je comprends pas ou tu veux en venir la
Tiens juste à titre d'exemple, deux benchmarks adodb ( le deuxième date un peu mais bon)
http://adodblite.sourceforge.net/benchmark.php
http://phplens.com/lens/adodb/
the_bigboo a écrit : et leur utilisation toujours pas tres bien expliquée, j'ai survollé adodb comme tu l'indiquait, mais ya aucune doc d'utilisation ou je suis aveugle |
T'es aveugle sur le lien donné, deuxieme ligne, "Documentation" et tu tombes sur
Marsh Posté le 28-04-2006 à 11:42:33
anapajari a écrit : Le truc que je trouve dommange c'est que des librairies d'accès à des bases de données pour le coup il en existe déjà plein en php alors pourquoi en refaire une
|
complètement d'accord avec toi, mais au moment où je me suis mis sur mon projet, j'en avais pas trouvé qui me plaisaient.
Adodb a l'air de roxer sa maman, j'ai presque envie de modifier mon projet à la volée lol.
Bon bah après avoir un peu regardé, cette classe fait tout ce dont j'ai besoin.
Le seul truc qui me manque (mais c'est ptet dedans), ça serait de pouvoir faire au sein d'une transaction des requetes qui peuvent planter sans annuler la transaction.
Et j'aimerais bien pouvoir empecher la base d'accepter de nouvelles requetes quand une requete plante (mais comme pour les transactions, que ça soit paramétrable).
Tu saurais si ce que je veux faire est facilement faisable avec cette classe ?
Marsh Posté le 28-04-2006 à 12:04:48
j'ai pas très bien compris ton problème
en gros tu as par exemple:
|
Et tu voudrais que si la requête 4 "plante", tu n'executes pas la 5 mais que les résultats produient par les 1,2 et 3 restent dans la base ou au contraire ne soient pas pris en compte?
Marsh Posté le 28-04-2006 à 12:57:38
j'aimerais deux choses :
- si la requete 4 plante, qu'on continue normalement, et sans annuler la transaction en cours
- si la requete 4 plante, la transaction en cours est annulée (ça aucun problème), mais plus aucune requete ne s'execute ensuite
Marsh Posté le 28-04-2006 à 13:51:50
http://www.phpscripts-fr.net/scrip [...] ration+BDD
http://www.comscripts.com/scripts/ [...] s.sc1.html
http://sourceforge.net/projects/alyoop
Marsh Posté le 28-04-2006 à 14:01:55
Bon sinon, j'ai matté la doc de ADODB (elle est très bien fait faut reconnaitre). Malheureusement, plusieurs points ne me donne pas envie de l'utiliser :
- un faible support de mysql 5, par exemple au niveau des procédures stockées.
- je voyais un intéret énorme en terme de portabilité. Et puis en fait non, cf les propres liens de ADODB : http://phplens.com/lens/adodb/tips_portable_sql.htm
Regardez la section 'SQL as a Localization Exercise'. Donc en gros ils te disent que pour être sur d'assurer une bonne portabilité, tu dois inclure des requêtes spécifiques à chaque bdd. Donc au final la portabilité elle est de 0 quoi.
Etant donné que j'ai déjà un "switcher" de base de données, si je dois réécrire les requetes, ça me coutera rien de plus de modifier également ma classe d'accès à la base.
(ADODB est très bien hein, simplement pour utiliser des fonctionnalités avancées des bdd, bah ils y peuvent rien mais c'est pas portable quoi).
Au final, l'intérêt que je vois à utiliser cette classe est que ça "standardise" l'accès à ta bdd, d'autres développeurs n'étant pas perdu s'ils ont déjà utilisé cette librairie. Mais au final, à part ça ...
Donc je préfère ma propre classe, qui inclue les fonctionnalités que j'aime, ni plus, ni moins. Je la commente un peu et je la poste comme convenu.
Marsh Posté le 28-04-2006 à 14:23:05
Djebel1 a écrit : j'aimerais deux choses : |
Pour moi, rien a voir avec la gestion des transactions. C'est plus de la gestion d'erreurs au sein de celles-ci et c'est le developpeur qui doit s'y coller
Djebel1 a écrit : |
Bin c'est sur que si tu utilises du SQL 'spécifique' à une BDD, la portabilité tu peux oublier
Djebel1 a écrit : Donc je préfère ma propre classe, qui inclue les fonctionnalités que j'aime, ni plus, ni moins. Je la commente un peu et je la poste comme convenu. |
L'argument ultime: "c'est moi qui l'a fait donc c'est mieux"
Marsh Posté le 28-04-2006 à 14:27:43
Djebel1 a écrit : Donc je préfère ma propre classe, qui inclue les fonctionnalités que j'aime, ni plus, ni moins. Je la commente un peu et je la poste comme convenu. |
C'est pour ca que j'ai développé la mienne ^^
Maintenant j'ai implémenté les jointures, j'ai passé la matinée a potasser les JOIN...
Utilisez vous plus INNER ? LEFT ? ou RIGHT ?
Marsh Posté le 28-04-2006 à 15:28:41
anapajari a écrit : |
pas du tout : c'est mieux pour moi car ça répond à mes besoins.
En fait j'en ai marre de devoir gérer les erreurs. Je me suis fait une classe qui me permet de ne plus jamais avoir à tester l'erreur provoquée par une requete. Et franchement, c'est la seule et unique raison pour laquelle je ne vais pas utiliser ADODB. Et j'ai bien souligné que je trouvais cette librairie très bien, mais que problème de portabilité pour problème de portabilité, je préfère faire chier le développeur suivant que moi
Marsh Posté le 28-04-2006 à 15:29:50
Citation : si tu utilises du SQL 'spécifique' à une BDD |
Le problème étant que pour certains trucs t'es obligé
edit : putain de bouton editer
Marsh Posté le 28-04-2006 à 15:36:51
Djebel1 a écrit : Le problème étant que pour certains trucs t'es obligé |
Oui... Par exemple l'attribut LIMIT ne passe pas sous oracle
Marsh Posté le 28-04-2006 à 15:49:59
bah ca encore ça va, ADODB te permet de gérer ce genre de problème. C'est pour les trucs pour lesquels ADODB n'a pas d'abstraction le problème
Marsh Posté le 28-04-2006 à 16:05:53
Voilà je vous soumets ma classe d'accès à une base MySQL :
Les intérêts qu'elle a pour moi (d'ailleurs c'est marrant, j'ai inclue des fonctionnalités qui se trouve dans ADODB )
- Gestion du debug : 3 niveaux de debug configurable : 1 pour voir toutes les requetes, 1 pour voir uniquement les requetes échouées, 1 pour la phase de prod
- Gestion du debug : mise dans un fichier log des erreurs mysql
- Gestion des transactions : le gestionnaire permet de ne pas imbriquer par erreur plusieurs transactions. Rollback toute transaction non confirmée à la fin de votre script.
- le test du retour des requêtes devient inutile : si une requete échoue, toute transaction sera automatiquement annulée, et la base n'acceptera plus aucune requete. Vous pouvez donc sereinement balancer une serie de requetes sans avoir à verifier la présence d'erreur. A la fin de votre "procédure", il vous suffit de vérifier en une seule instruction si une erreur s'est produite.
Un paramètre optionnel permet de ne pas obtenir ce comportement : une requete échouée ne provoquera pas l'annulation de la transaction, et la base continuera d'accepter des requêtes.
- multiton pattern : votre classe est appelable de n'importe où, et vous garantit la présence d'une seule instanciation en mémoire par connection. Vous pouvez gérer plusieurs connexions simultannées.
- pas de trucs compliqués pour gêrer les requetes, vous pouvez donc toutes les faire. Bien sur, cela implique que si vous changez de bdd, il faudra réécrire les requetes dans votre couche de persistance. Mais comme de toute façon si vous changez de bdd vous devrez réécrire vos requetes ... (comme on en a discuté, une abstraction totale de la bdd est impossible)
Code :
|
Marsh Posté le 28-04-2006 à 17:16:04
moi j'aurais fais une fonction startTransaction, rollback et commit, a la place transactionManager
Parce que ton switch, tu fais une faute de frappe dans $action, il va pas te dire que ça marche pas (quoique, y'a pas de default).
Marsh Posté le 29-04-2006 à 00:59:15
Sinon ya les classes mysqli et PDO (qui implémente un drivers pour sqlite, oracle, pgsql et mysql) et qui sont inclus dans PHP5
Marsh Posté le 29-04-2006 à 10:20:28
the_bigboo a écrit : Maintenant j'ai implémenté les jointures, j'ai passé la matinée a potasser les JOIN... |
Ca dépend totalement du type de requête voulu.
Exemple simple: 2 tables liées par une relation 0/1 vers n style voiture-marque (avec certaines voitures sans marque, bon je trouve rien deplus pertinent)
Si tu requêtes toutes les voitures avec leur marques dans une requête avec jointure simple (style "from voiture, marque where voiture.marque=marque.id" ), tu n'obtiendras que les voitures ayant une marque (que les voitures où l'identifiant "marque" est rempli) et ça n'affichera pas les voitures sans marque.
Si ton but est d'obtenir toutes les voitures, et d'afficher en plus la marque pour les voitures qui en ont une, alors faut demander un "outer join".
Pour les "left" et "right", c'est aussi d'autres caractéristiques correspondant à d'autres pb similaires. On peut pas dire qu'il faut toujours du left ou toujours du right...
Marsh Posté le 29-04-2006 à 18:57:47
Sve@r a écrit : |
Pourquoi pas INNER ?
Marsh Posté le 30-04-2006 à 01:24:49
qq idées en vrac:
J'ai découvert le bind de valeurs avec Qt:
Code :
|
C'est peut être le truc le plus interessant.
Sinon, ça me paraît un poil compliqué. J'ai pas tout lu, mais de loin ça ressemble à un nid à bugs. Quand tu jongle bien avec le SQL (qui finalement n'est pas très compliqué) tu peut te passer de la plupart des fonctionnalités ci-dessus.
Ce qui est paraît interessant, c'est la gestion des plantages. Mais j'en connais pas qui soit vraiment utile dans tous les cas.
Un autre truc que j'utilise souvent: une liste de conditions de longueur variable comme dans une page de recherche avec champs facultatifs.
Finalement, ce que je préfère, c'est une classe à part pour encapsuler les requêtes, selon les objets et la base. Je trouve ça plus facile à débugger.
Marsh Posté le 04-05-2006 à 09:36:43
c'est pour ca que j'ai fait cette class ! Mes besoins sont pas extraordinaires !elle est adaptée a mes besoins et c'est pratique c'est tout
Marsh Posté le 04-05-2006 à 09:51:54
Je@nb a écrit : Sinon ya les classes mysqli et PDO (qui implémente un drivers pour sqlite, oracle, pgsql et mysql) et qui sont inclus dans PHP5 |
Attention toutefois à PDO, qui n'est pas une librairie d'abstraction de source de donnée, mais une librairie d'abstraction d'accès aux donnée. Si on code en PDO pour mysql et qu'on fait pas gaffe, y'a de forte chance qu'il faille réécrire toutes les requêtes lors du passage à un autre systus.
AdoDb, par contre, est vraiment un machin d'abstraction de bidule, à savoir que toutes les requêtes sont écrites une fois pour toutes, qu'on soit sous MySql, Oracle, etc.
Marsh Posté le 04-05-2006 à 09:53:32
the_bigboo a écrit : voila j'ai fait cette petite class en PHP5 car je trouve que meme si c'est assez facile de gérer ses requetes SQL, c'est bien pratique car le code en est d'autant plus simplifié. Elle fait tout de meme 650 lignes
|
J'aurais pas utilisé extends pour MySQL_insert, j'aurais plutôt mis un objet MySql dans MySQL_insert
Marsh Posté le 04-05-2006 à 11:17:22
probablement, mais l'objet MySQL sert pour d'autres objets aussi... Notament pour charger la configuration.
Marsh Posté le 04-05-2006 à 11:20:47
Là je pense qu'il y a un problème de structure. Tu utilises extends pour utiliser les fonctionnalités de MySQL. MySQL_Insert n'est pas un objet de type MySQL, c'est un objet qui utilise MySQL. You failed Essaye de revoir tes notions de l'orienté objet
Marsh Posté le 04-05-2006 à 11:43:23
FlorentG a écrit : Là je pense qu'il y a un problème de structure. Tu utilises extends pour utiliser les fonctionnalités de MySQL. MySQL_Insert n'est pas un objet de type MySQL, c'est un objet qui utilise MySQL. You failed Essaye de revoir tes notions de l'orienté objet |
ben tu ferais ca comment toi ? Je vois pas d'autres moyens ! Si je déclare un objet dans l'objet ca va faire du copier/coller de ouf !
En quoi est-ce une faute puisque ca marche tres bien comme ca ??
Marsh Posté le 28-04-2006 à 00:05:11
voila j'ai fait cette petite class en PHP5 car je trouve que meme si c'est assez facile de gérer ses requetes SQL, c'est bien pratique car le code en est d'autant plus simplifié. Elle fait tout de meme 650 lignes
donc l'avantage ,c'est qu'au lieu de faire :
vous ferez :
Le gain ne se situe pas sur la longueur du code qui ne change que tres peu, ca permet surtout un évolution nettement plus facile
Les procédures sont sensiblements les memes pour les autres classes, le gain de se fait pas sur la compacité du code mais sur sa facilité a évoluer.
En espérant que ca vous aidera autant que ca m'aide, j'integrerai sous peu les jointures dans la class SELECT
En passant j'aimerais avoir des suggestions d'optimisation ou des idées, bref des avis...
Message édité par the_bigboo le 28-04-2006 à 00:49:19