PHP

Class PHP5 de gestion de requetes SQL simples

Recherche :

Mot : Pseudo : Filtrer
Page : 1 2 Page Suivante Page Précédente Bas de page
Auteur	Sujet : Class PHP5 de gestion de requetes SQL simples

the_bigboo

Reprise du message précédent :

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 ??

Publicité

FlorentG

Unité de Masse

[:le kneu] Oh maman

Message cité 1 fois
Message édité par FlorentG le 04-05-2006 à 11:51:28

the_bigboo

FlorentG a écrit :

[:le kneu] Oh maman

:??:

Tu sugerre que je fasse un include a chaque fois ?

Message édité par the_bigboo le 04-05-2006 à 11:52:29

FlorentG

Unité de Masse

Déjà il y a un problème conceptuel : les objets MySQL_Insert, MySQL_Update, etc. ne sont pas des objets MySQL, mais des objets symbolisant une requête. Donc déjà la classe MySQL devrait accepter en paramètre de la méthode exécute un objet implémentant une interface que je nommerais Query (genre avec dedans une méthode getQueryText()).

Si tu veux pas trop modifier, je ferais en sorte que les objets MySQL_Insert, etc. prennent dans le constructeur une instance de MySQL, surlaquelle on exécutera la requête. Mais spatop d'un point de vue conceptuel, même si c'est déjà un peu mieux. En même temps, ça permet de partage un même objet MySQL. Sinon là, si tu instancie un insert et un select, t'as cash deux MySQL qui sont créer, avec les variables qui ont les mêmes valeurs, pas très effciient

the_bigboo

que j'initialise une instance de chaque objet dans le constructeur de classe MySQL ?

FlorentG

Unité de Masse

Alors ça dépend de l'approche que tu prends. Je conseillerais un truc du style :

class MySql {

[...]

public function execute_query(Query $query) {
mysql_query($query->getQueryText());
}
}

Avec tes objets qui implémentent l'interface Query et la méthode getQueryText().

Sinon passé en constructeur des trucs l'objet MySql :

class MySql_Insert {

private $mysql;
private $query;

public function __construct(MySQL $mysql) {
$this->mysql = $mysql;
}

public function execute() {
$this->mysql->execute($this->query);
}
}

Ca marcherait aussi.

Djebel1

Nul professionnel

FlorentG a écrit :

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.

bah ouais mais non http://phplens.com/lens/adodb/tips_portable_sql.htm

Citation :

In general to provide real portability, you will have to treat SQL coding as a localization exercise. In PHP, it has become common to define separate language files for English, Russian, Korean, etc. Similarly, I would suggest you have separate Sybase, Intebase, MySQL, etc files, and conditionally include the SQL based on the database. For example, each MySQL SQL statement would be stored in a separate variable, in a file called 'mysql-lang.inc.php'.

Message cité 2 fois
Message édité par Djebel1 le 04-05-2006 à 12:15:11

anapajari

s/travail/glanding on hfr/gs;

Djebel1 a écrit :

bah ouais mais non http://phplens.com/lens/adodb/tips_portable_sql.htm

Mais je reste pas d'accord
Si tu fais tes requêtes de façon "standardisée"(SQL-92) via adoDB tu n'auras rien a changer.

Maintenant j'aimerais bien que tu m'expliques l'intêret d'utiliser une bibliothèque d'abstraction si c'est pour passer des requêtes avec une syntaxe spécifique à une DB... c'est un peu le serpent qui se mort le queue [:mlc]
"Je veux faire une appli qui fonctionne sur tous les SGBD, mais même avec une bibliothèque d'abstraction quand je mets du SQL spécifique à MySQL, ça marche pas avec DB2/ORACLE..."

Message édité par anapajari le 04-05-2006 à 12:25:00

Djebel1

Nul professionnel

>Maintenant j'aimerais bien que tu m'expliques l'intêret d'utiliser une bibliothèque d'abstraction
c'est bien pour ça que j'en utilise pas.

>Si tu fais tes requêtes de façon "standardisée"(SQL-92) via adoDB tu n'auras rien a changer
Bah écoute c'est pas moi qui le dit qui faut inclure différentes requetes pour différentes bdd, c'est le site d'AdoDB lui-même hein ^^
Si tu utilises des fonctionnalités avancées de ta bdd, AdoDB ne pourra pas faire d'abstraction portable sur toutes les autres bdd.
Après je dis pas, si tu as juste des requêtes de base, np.

the_bigboo

djebel a raison, l'avantage du SQL-92, c'est l'aspect portabilité de l'application finale !

Message cité 1 fois

Publicité

Djebel1

Nul professionnel

the_bigboo a écrit :

djebel a raison, l'avantage du SQL-92, c'est l'aspect portabilité de l'application finale !

euh, moi jdis justement que t'auras beau faire, ça sera pas portable

Message cité 1 fois

the_bigboo

Djebel1 a écrit :

euh, moi jdis justement que t'auras beau faire, ça sera pas portable

ben t'a que le nom des fonction a changer c'est tout !

Djebel1

Nul professionnel

Djebel1 a écrit :

bah ouais mais non http://phplens.com/lens/adodb/tips_portable_sql.htm

jme répète, mais c'est pas moi qui le dit, c'est AdoDB. Et si tu dois inclure des requêtes différentes en fonction de la bdd, y a pas de portabilité.
Et je me re re répète, bien sur avec des requetes de base y a pas de soucis, si t'utilises des fonctionnalités avancées tu l'as dans le cul

>ben t'a que le nom des fonction a changer c'est tout !
quand bien même tu n'aurais que ça à changer (ce qui est faux), j'appelle pas ça de la portabilité

Message cité 1 fois
Message édité par Djebel1 le 04-05-2006 à 12:54:39

the_bigboo

Djebel1 a écrit :

C'est ce que je dis depuis tout a l'heure :ange:

Djebel1 a écrit :

>ben t'a que le nom des fonction a changer c'est tout !
quand bien même tu n'aurais que ça à changer (ce qui est faux), j'appelle pas ça de la portabilité

Ce que je veux dire , c'est que tu n'a que quelques trucs a changer, et encore quand je dis a changer, c'est prévu dans un autre librairie, seul les fonctions appelées changent ! Ex : mysql_connect et oci_login

FlorentG

Unité de Masse

FlorentG a écrit :

bah ouais mais non http://phplens.com/lens/adodb/tips_portable_sql.htm

Ben ouais mais si. Le paragraphe que t'as quoté, c'est dans des cas extrêmes. AdoDb file tout ce qu'il faut pour éviter de devoir refaire. Genre pour les limites, pour le nombre d'enregistrements retournés, etc. Après il y a évidemment toujours des petites différences...

Bon, moi en tous cas j'utilise pas, je code tout en dur pour MySql, parce que la probabilité de changer de SGBD est pour l'instant infime...

Djebel1

Nul professionnel

>c'est dans des cas extrêmes
oui oui je dis pas du tout le contraire. Moi je tombe dans ce genre de cas, donc voilà

Message cité 1 fois

anapajari

s/travail/glanding on hfr/gs;

Djebel1 a écrit :

>c'est dans des cas extrêmes
oui oui je dis pas du tout le contraire. Moi je tombe dans ce genre de cas, donc voilà

Je serais assez curieux que tu nous présentes un de ces "cas SQL extrèmes" où tu ne peux pas t'en sortir avec du SQL standard [:mlc]

Message cité 1 fois

Djebel1

Nul professionnel

anapajari a écrit :

Je serais assez curieux que tu nous présentes un de ces "cas SQL extrèmes" où tu ne peux pas t'en sortir avec du SQL standard [:mlc]

Bah écoute je croyais avoir vu la super requête de la mort qui tue avec update multitable en select imbriqué, en lisant la doc la première fois j'avais cru voir que c'était la merde, et en fait, non. Je m'incline :jap:

Djebel1

Nul professionnel

hmm, dis moi, je comprends pas bien comment sont gêrés les champs auto_increment avec AdoDB. Pour que ça soit portable, tu dois utiliser la fonction GenId() disent-ils.
En l'occurence, ça crée une table uniquement pour stocker le dernier ID. C'est normal ? c'est pas un peu balaud ?

FlorentG

Unité de Masse

C'est justement là où ça peut être difficile d'avoir un truc qui abstrait tout. C'est pour ça que moi je m'en tiens à MySql... Limite j'utiliserais les PDO dès qu'OVH met à jour PHP5 vers la 5.1, ça fera au max certaines requêtes à modifier si jamais je change de SGBD, ce qui est assez improbable là tout de suite

Djebel1

Nul professionnel

bah en même temps, c'est pas très grave, si ça permet d'être portable. Par contre, c'est au niveau des joiture externes que je comprends pas bien comment c'est géré. Visiblement, il faut utiliser une syntaxe caca, comme :

Code :

SELECT t1.col1, t1.col2, t2.cola FROM t1, t2
WHERE t1.col = t2.col
UNION ALL
SELECT col1, col2, null FROM t1
WHERE t1.col not in (select distinct col from t2)

Vous confirmez que ces syntaxes sont portables ?

Et pour les jointures internes ? C'est portable d'utiliser "inner join on blabla" ? J'ai rien vu à ce sujet

Message édité par Djebel1 le 05-05-2006 à 12:05:37

Je@nb

Kindly give dime

C'est un peu crade je trouve ta requette pour faire une simple jointure externe, tu fous un OUTER LEFT JOIN et hop osef des SGBD qui comprennent pas

Message cité 1 fois

anapajari

s/travail/glanding on hfr/gs;

Citation :

SQL92-Standard joins notes

INNER JOIN The result consists of rows from T1 paired with rows from T2, filtered with the required ON clause. This is similar to a "traditional" join done in the WHERE clause.
CROSS JOIN This creates a Cartesian product of the rows in both tables, just like when the WHERE clause is forgotten. This join can not be used with the ON clause.
The USING clause TBD

The ON clause This syntax allows you to specify the column names for join keys in both tables.

LEFT OUTER JOIN This returns all the rows from the table on the left side of the join, along with the values from the right-hand side, or nulls if a matching row doesn't exist.
RIGHT OUTER JOIN This returns all the rows from the table on the right side of the join, along with the values from the left-hand side, or nulls if a matching row doesn't exist.
FULL OUTER JOIN This returns all rows from both tables, filling in any blanks with nulls (see important notes below.)

Some portability notes:

The default behavior for JOIN without any specifier (OUTER, CROSS, INNER...) may vary between vendors. It is recommended not to rely on such a default and always use JOIN with the intended specifier. For example, Oracle defaults to a INNER join, while MySQL defaults to a CROSS join.
FULL joins is buggy on MySQL, version 4.0.3-beta. It does not accept any ON clause and seems to behave like a CROSS join.
The JOIN syntax is not supported on PostgresSQL 6.x and below.
The JOIN syntax is not supported on Sybase 11.x and below.

donc

Message édité par anapajari le 05-05-2006 à 15:33:39

Djebel1

Nul professionnel

donc :
- bidouille infame pour les champs auto_increment
- syntaxe de merde pour les jointures
- pas d'abstraction pour les appels de procédure (voir "stored procedures" toujours ici http://phplens.com/lens/adodb/tips_portable_sql.htm )

= pas de portabilité = bah non en fait j'utiliserai pas de librairie d'abstraction ^^

Je@nb a écrit :

C'est un peu crade je trouve ta requette pour faire une simple jointure externe, tu fous un OUTER LEFT JOIN et hop osef des SGBD qui comprennent pas

bah ouais, mais c'est pas ma requête, c'est ce qu'ils conseillent de faire pour être "portable" :sweat:

Message cité 1 fois
Message édité par Djebel1 le 05-05-2006 à 15:40:41

anapajari

s/travail/glanding on hfr/gs;

Djebel1 a écrit :

- bidouille infame pour les champs auto_increment

!
Bin ça existe(ait) pas sur tous les SGBD auto-increment!!!
Par exemple sur DB2(pas la moins connue), cela n'existe que depuis la version7(6refresh pour les puristes) et encore la syntaxe est batarde:

Code :

CREATE TABLE EXAMPLE
(ID_COL INTEGER NOT NULL
GENERATED ALWAYS AS IDENTITY
START WITH 1
INCREMENT BY 1
...);

Djebel1 a écrit :

- syntaxe de merde pour les jointures

Tu as pas lu mon msg, les jointures c'est "standard" donc je vois pas pourquoi s'en priver. Et si tu as besoin de porter ton appli sur un truc qui supporte par le SQL92 bonne chance, avec ou sans librairie d'abstraction...

Djebel1 a écrit :

- pas d'abstraction pour les appels de procédure (voir "stored procedures" toujours ici http://phplens.com/lens/adodb/tips_portable_sql.htm )

Etant donné que chaque sgbd a en gros "son" langage de procédure ça parait normal... Encore une fois dans le cadre du developpement du appli portable sur plusieurs BDD, l'utilisation abusive de procédure me parait plus que déconseillée.

Djebel1 a écrit :

= pas de portabilité = bah non en fait j'utiliserai pas de librairie d'abstraction ^^

C'est surtout que pour l'instant, tu n'as jamais eu a devoir porter une application pour ne pas voir l'interêt!!!

Message cité 1 fois
Message édité par anapajari le 05-05-2006 à 15:54:47

Djebel1

Nul professionnel

anapajari a écrit :

Bin ça existe(ait) pas sur tous les SGBD auto-increment!!

si c'était le seul problème, ça ne serait effectivement pas un pbl la façon dont AdoDB le gère.

anapajari a écrit :

Tu as pas lu mon msg, les jointures c'est "standard" donc je vois pas pourquoi s'en priver.

bah si j'ai bien lu ton message, les join ne marchent pas sur toutes les bases, ou alors j'ai mal compris.
Et le SQL-92 c'est bin beau, mais je lis aussi

Citation :

Furthermore the syntax for outer joins differs dramatically between database vendors

anapajari a écrit :

Devoir se priver de procédures stockées, tu m'accorderas que c'est un gros désavantage quand meme.

anapajari a écrit :

C'est surtout que pour l'instant, tu n'as jamais eu a devoir porter une application pour ne pas voir l'interêt!!!

Bah si, et étant donné que j'ai une surcouche pour l'accès aux données, concrètement je n'ai que à réécrire les requêtes, ce qui est franchement pas méchant.

Enfin à chaque fois tu es à la limite de me convaincre (tu m'as même convaincu hier), tes arguments sont tout à fait valables.
Mais quand même :
- ne pas pouvoir utiliser la norme SQL pour les jointures (c'est ce qui m'emmerde le plus à vrai dire, pour les jointures externes)
- ne pas pouvoir utiliser de procédure stockées
- tout ça alors que je n'ai que à réécrire mes requêtes pour que mon appli soit portable.

Franchement, tu trouves pas que c'est bcp d'emmerdes pour pas gd chose ?

Message cité 1 fois
Message édité par Djebel1 le 05-05-2006 à 16:05:30

anapajari

s/travail/glanding on hfr/gs;

Djebel1 a écrit :

Mais quand même :
- ne pas pouvoir utiliser la norme SQL pour les jointures (c'est ce qui m'emmerde le plus à vrai dire, pour les jointures externes)

Alors dans SQL-92 , le 92 veut dire 1992... Tu comprends bien que les SGBD ont quelque peu evolués depuis (enfin pas tant que ça puis oracle supporte tout juste SQL99(qui n'apporte pas grand chose))

Djebel1 a écrit :

- ne pas pouvoir utiliser de procédure stockées

C'est plus le problème, je suis d'accord. Mais si dès le départ tu dev une appli en ayant en tête une possible utilisation sur différentes BDD, c'est une contrainte que tu prends en compte dès le départ!

Djebel1 a écrit :

- tout ça alors que je n'ai que à réécrire mes requêtes pour que mon appli soit portable.

Et toutes tes procédures [:aloy] en esperant que tu puisses les transcrire sur le nouveau sgbd.

Djebel1 a écrit :

Franchement, tu trouves pas que c'est bcp d'emmerdes pour pas gd chose ?

Le vrai emmerdement en fait, il est de porter une appli d'une bdd sur une autre!!!

Djebel1 a écrit :

Enfin à chaque fois tu es à la limite de me convaincre (tu m'as même convaincu hier), tes arguments sont tout à fait valables.

Le but n'est pas de convaincre de l'utiliser mais de convaincre de l'utilité... Après est-ce vraiment nécessaire sur le projet sur lequel tu travailles c'est une autre histoire!

Message édité par anapajari le 05-05-2006 à 16:25:39

Djebel1

Nul professionnel

>Après est-ce vraiment nécessaire sur le projet sur lequel tu travailles c'est une autre histoire!
un projet open-source, ça serait clairement un plus

>Et toutes tes procédures
pas faux

>Alors dans SQL-92 , le 92 veut dire 1992
Ouais et alors au final, aujourd'hui c'est la merde pour les jointures ou pas ? J'arrive pas à comprendre si tu dis que c'est le gros bordel, ou si c'est bien standardisé désormais

J'avoue que c'est l'élément principal qui me retient : si je dois utiliser des syntaxes à la con pour mes jointures, je laisse tomber direct

Message cité 1 fois

anapajari

s/travail/glanding on hfr/gs;

Djebel1 a écrit :

>Alors dans SQL-92 , le 92 veut dire 1992
Ouais et alors au final, aujourd'hui c'est la merde pour les jointures ou pas ? J'arrive pas à comprendre si tu dis que c'est le gros bordel, ou si c'est bien standardisé désormais
J'avoue que c'est l'élément principal qui me retient : si je dois utiliser des syntaxes à la con pour mes jointures, je laisse tomber direct

C'est bien standardisé ... et l'implémentation est bonne !!! Tu peux utiliser des jointures sur db2, oracle, postGre, Mysql ...
Mais si tu regardes bien, au sein d'un même sgbd ( au pif mysql) entre les versions ( la 3 et la 5 par exemple) c'est déjà pas pareil [:spamafote]

Djebel1

Nul professionnel

tous les types de jointure sont bien standardisées, même les jointures externes ? Tu me dis donc que je peux utiliser la syntaxe "officielle" ?
(désolé mais je sais pas trop où chercher cette info à part dans la doc de chaque db, et comme t'as l'air de t'y connaitre ...)

anapajari

s/travail/glanding on hfr/gs;

tiens j'ai trouvé sur cette page

Citation :

4. Le « JOIN » n'est pas supporté par toutes les bases de données. Oracle à dû attendre la version 9 alors que MySQL la version 3.23.17 pour le « INNER JOIN »! et MySQL 4.0.11 pour le « UNION » et « CROSS JOIN » (mise à jour 2004). Pour leur part, PostGreSQL se limite au « LEFT », « RIGHT » alors que DB2, bien que très puissant, au « LEFT ».

Mais je sais pas ce que ça vaut vu que pour DB2 c'est n'importe quoi [:spamafote]

Djebel1

Nul professionnel

ouep en effet, ça date de 2000
bon bah j'ai plus qu'a me taper la doc de 3 ou 4 bdd quoi. Je vous ferai part de mes résultats d'investigation

Je@nb

Kindly give dime

Les syntaxes pour appeler une procédure stockées sont différentes ou pas selon le SGBD ?

Car si c'est toujours la même syntaxe dans ce cas il suffit d'appeler la procédure stockées qui elle fait la requette spécialement faite pour le SGBD qui va bien, mais je doute qu'on appelle une procédure stockée de la même manière entre SQL Serveur, Oracle et Mysql

FlorentG

Unité de Masse

Bon, j'ai presque fini ma lib à moi... Bon y'a pas trop de génération de requêtes (ça viendra peut-être), j'ai pu voir qu'avec les 255 cas qu'on peut rencontrer (genre rien qu'avec les JOIN), le mieux encore était de faire une simple gestion de requêtes paramétrées : on balance le texte de la requête en dur, avec genre des points d'interrogation à la place de là où on veut les valeurs. Puis on envoi un tableau avec les valeurs (dans l'ordre d'apparition dans la requête), et hop, on l'exécute.

J'ai encore 2-3 truc à faire dessus. J'ai aussi, cette fois-ci, fait des tests unitaires pour être sûr que rien ne foire en cas de refactorisation. J'ai utilisé PHPUnit2, qui est pas trop mal (bien que la gestion des Mocks n'arrivera que pour la prochaine version)

Djebel1

Nul professionnel

fais pêter le code, ou un lien vers les fichiers

Message édité par Djebel1 le 12-05-2006 à 17:51:59

FlorentG

Unité de Masse

Ouais attend, spafini

FlorentG

Unité de Masse

Voilà un early-test :

public function testPreparedSelect()
{
$queryText = "SELECT * FROM `tableTest` "
. "WHERE `id`=@int AND `name`=@string AND `prename`=@string "
. "AND `pass`=@string AND `content`=@string "
. "AND `pouet` LIKE '%@like%' AND `a`=@int";

$query = new Data_MysqlQuery($queryText, $this->mysql);

$query->prepare(5, 'john', 'SomeValue@string', "' OR 1=1 --", "First Line\r\nSecond Line", '%Some_Value%', '245');

$this->assertEquals($query->getQueryText(),
"SELECT * FROM `tableTest` WHERE `id`=5 AND `name`='john' AND `prename`='SomeValue@string' "
. "AND `pass`='\' OR 1=1 --' AND `content`='First Line\\r\\nSecond Line' "
. "AND `pouet` LIKE '%\\%Some\\_Value\\%%' AND `a`=245" );
}

Donc gestion de requêtes paramétrées. On met dans la requête à la place des valeurs un placeholder qui renseigne sur le type, puis on balance les valeurs, et hop ! Il escape tout comme il faut [:dawa] Y'a après des méthodes pour exécuter différents types de requêtes : requêtes normalles, requêtes sans résultat, requêtes ne retournant qu'une seule ligne ou requête ne retournant qu'une seule valeur

FlorentG

Unité de Masse

Bon, j'ai modifié 2-3 trucs, voilà ce que ça donne par exemple avec 2 select + un insert :

public function add($data)
{
$query = new Data_MysqlQuery(
'SELECT MAX(`order`) FROM `categorie` WHERE `parent`=@int', $this->mysql);
$order = (int)$query->executeValue($data['parent']) + 1;

$query = new Data_MysqlQuery(
'SELECT `path` FROM `categorie` WHERE `id`=@int', $this->mysql);
$path = $query->executeValue($data['parent']) . '_' . $data['parent'];

$query = new Data_MysqlQuery(
'INSERT INTO `categorie`(`parent`, `order`, `title`, `child`, `path`) '
. 'VALUES(@int, @int, @string, @string, @string)', $this->mysql);

$query->executeNoResult($data['parent'], $order, $data['title'], $data['child'], $path);
}

Djebel1

Nul professionnel

fais voir la classe Data_MysqlQuery aussi ça serait intéressant

Message édité par Djebel1 le 16-05-2006 à 16:27:20

FlorentG

Unité de Masse

Euh ouais, faut juste que je termine 2-3 trucs dessus, genre rajouter des types de paramètres...

Publicité

Page : 1 2

Page Suivante

Page Précédente

Haut de page

FORUM HardWare.fr

Programmation

PHP

Class PHP5 de gestion de requetes SQL simples

Sujets relatifs
convertir base de donnée excel en base de donnée SQL	Mailing list + gestion contacts (adresse postale...)
[VB.NET CF2.0] Sql server CE	[SAGE] requete sql via odbc sous sage gestion commercial ligne 100
assembleur ARM - petites questions simples	[PHP] Interface de gestion d'un menu customizable...
[MFC et ODBC] Requete SQL	Gestion des membres via cookie
Gestion des membres via cookie	Comment ouvrir les fichiers *.class?
Plus de sujets relatifs à : Class PHP5 de gestion de requetes SQL simples

Page générée en 0.117 secondes