[Plan du site] Vous êtes ici --- > Le Site du Zér0 > Les tutoriels > Non-Officiels > Site Web > PHP > Base de données > Lecture des commentaires

Vos commentaires sur :
PDO : Interface d'accès aux BDD

Retour au tutoriel

Vous devez être inscrit pour pouvoir poster des messages

Page : 1

Pseudo

Commentaire

Page : 1

Piwaï

# Posté le 16/06/2006 08:07:17

Why can't we be friend ?

Groupe : Membres

Pas mal pas mal, c'est assez interessant, et plutot bien rédigé.

EDIT : les erreurs que j'indiquais ont désormais été corrigées . Merci pour la promptitude de réaction de l'auteur .

dans la partie sur prepare :

Citation : tuto

Ces marqueurs ne sont pas mangeables

Sérieux ? Bah mince, moi qui salivais à l'idée de manger des marqueur... C'étais po plutôt mélangeable que tu voulais dire ?

.

En même temps, comme tu finis par "Bref, PDO, mangez en c'est bon.", c'est peut-être une métaphore filée...

Sinon, quand tu fais :

$connexion->exec("UPDATE membres SET mot_pass=$mot_passe");

Ca serait po plutot :

$connexion->exec("UPDATE membres SET mot_pass='$mot_passe'"); ? En tout cas si le mot de passe est une chaine de caractère... Comme je connais pas PDO, je suis pas sur, mais avec le classique mysql_query, ca marcherait po...

Si j'avais un petit reproche à faire, certains points manquent un peu de précision, tu nous apprend une méthode et une seule..

Ainsi, pour PDO::FETCH_ASSOC , PDO::FETCH_BOTH , PDO::FETCH_OBJ , bah.. On sait pas trop a quoi correspondent chacun, et vu que c'est pas indiqué non plus dans un tuto de M@teo (il me semble), bon tu nous dit que tu préfère OBJ, okey, mais... Il serait interessant de savoir les différences. A moins qu'il n'existe un tuto qui en parles déjà, et dans ce cas un chtit lien vers le tuto ne serait pas de refut

.

Voila voila !!

@++

Piwaï

http://www.piwai.info
"La violence est le dernier refuge de l'incompétence". Isaac Asimov, Fondation.
Créateur de 2H4U : Too Hard For You et découvrez aussi BisouLand.

Draeli

# Posté le 16/06/2006 09:23:20

Groupe : Membres

Edit :
Pour le $connexion->exec je viens te refaire le test sur une config moins exotique et ca marche bien comme on pourrais s'y attendre, le tuto a donc étais modifié pour refléter ca

Pour la faute de frappe c'est bon c'est mis à jour, merci au validateur pour la mise à jour

Concernant les divers modes de récupération pour les résultats je m'y affaire dès que j'ai le temps

Jedi PHP (Certifié Zend PHP) - Jedi MySQL (Certifié MySQL Core) - Padawan MySQL 5
Le côté obscur de la force bientôt rejoins ai-je ! :-°

bracor

# Posté le 16/08/2006 20:14:31

Ravioli.

Groupe : Membres

Même en relisant, je trouve que ton tuto rentre trop vite dans le code, je pense que tu devrais plus déveloper les points suivants :

Pourquoi l'utiliser?
Ah bon, y'a autre chose que mysql?

Gaga971

# Posté le 27/01/2007 18:29:03

Programmeur indépendant
Avatar

Groupe : Membres

Ben il va quand même pas faire tout un pagraphe juste pour tes deux questions ...
Les personnes qui viennent lire ce tutoriel sont apote a comprendre, il est surtout approprié aux personnes qui font des scripts a porposer au grand public.Ce serait plutot les question qu'il auarit du developper.

Tot

# Posté le 07/07/2007 14:43:59

Groupe : Membres

Les ", cay mal !

Code : PHP

$connexion = new PDO("mysql:host=$PARAM_hote;port=$PARAM_port;dbname=$PARAM_nom_bd", $PARAM_utilisateur, $PARAM_mot_passe);

devrait donner :
Code : PHP

PDO('mysql:host='.$PARAM_hote.';port='.$PARAM_port.';dbname='.$PARAM_nom_bd, $PARAM_utilisateur, $PARAM_mot_passe);

C'est (un peu) plus rapide au niveau de l'éxécution (même si c'est plus long à taper).

Sinon bon tuto, je crois juste que j'aurais du mal à me défaire de mes habitudes, et surtout à aller modifier toutes les requètes déja écrites de mes pages...

17/20

jspa

# Posté le 29/12/2007 16:03:05

Groupe : Membres

Et si tu activais la coloration syntaxique ?

gtraxx

# Posté le 31/01/2008 02:24:22

clashdesign
Avatar

Groupe : Membres

Bien bien mais tu devrais le complèter avec quelque exemple avec bindParam, binValue, et pourquoi pas un mini intro au transaction

La plus grande force dans la réalisation de ses projets est bien entendu l'entraide.
clashdesign
dj gtraxx
Ma plateforme de blog : Blogle
https://wiki.ubuntu.com/GeritsAurelien

`Haku

# Posté le 15/03/2008 16:23:20

**Rose**

Citation : Tuto

Pas vraiment, car s'il est vrai que certaines requêtes devront être ré-écrites spécifiquement, beaucoup -de par le mécanisme qui sous tend PDO- resteront valables ; en fait, l'intérêt de PDO n'est pas là mais que le code n'aura plus à être ré-écrit : c'est là l'avantage majeur de PDO.

Si c'est là l'avantage majeur de PDO, alors PDO est un non-sens. Il n'y a absolument pas besoin de PDO pour ne pas avoir à réécrire le code de traitement quand on change le code de manipulation de données.

Et d'ailleurs, PDO souffre d'un problème majeur : il implique que les données soient dans une base de données. Si on fait un livre d'or avec PDO et qu'après on veut stocker les messages dans des fichiers, on devra réécrire le code de récupération de données et le code de traitement.
Alors que si on avait séparer proprement la couche de récupération de données de la couche de traitement, seul la couche de récupération devrait être modifiée.

Et même si on reste dans le cadre des bases de données, PDO ne permet pas de s'affranchir d'un énorme travail. Ca évite de devoir changer des mysql_query par pgsql_query, ça permet d'éviter de réécrire une partie du code de traitement. Mais ce n'est qu'une petite partie du problème. Le vrai problème, c'est qu'il faut repenser toute la base de données, réécrire toutes les requêtes, et réécrire le code de traitement en fonction des requêtes (oui, en fonction du SGBDR, on utilisera pas forcément les mêmes techniques, et comme le code de traitement dépend des techniques utilisées, même avec PDO, le code de traitement devra changer en partie).

Bref, PDO, on le présente comme un truc génial, mais c'est loin d'être si génial.
Ca ne permet pas de s'affranchir de la réécriture des requêtes ;
Ca ne permet pas de s'affranchir de refaire toute la structure de la base ;
Ca ne permet pas de s'affranchir des modifications à apporter au code de traitement.

Envie d'apprendre le PHP ou le SQL ?
Envie d'en savoir plus sur le PHP ou le SQL ?
Suivez le guide...

Draeli

# Posté le 15/03/2008 16:54:08

Groupe : Membres

Citation : 'Haku

...

Bref, PDO, on le présente comme un truc génial, mais c'est loin d'être si génial.
Ca ne permet pas de s'affranchir de la réécriture des requêtes ;
Ca ne permet pas de s'affranchir de refaire toute la structure de la base ;
Ca ne permet pas de s'affranchir des modifications à apporter au code de traitement.

Je présente ca comme étant quelque chose de bien pas comme étant parfait (enfin j'espère en tous cas que ca n'est pas compris comme ca).

1 : Non effectivement ca ne permet pas de s'affranchir de la ré-écriture de requête sauf si on fait des requêtes SQL conforme au standard (tous comme le xhtml, on a le droit de ne pas le respecter mais après certains navigateurs jetteront une partie du code comme étant illisible donc à charge du développeur de prendre en compte ce fait).

2 : Dans la mesure ou la structure est faite, que tu sois sur un SGBD x ou y la modélisation reste la même, après tu auras toujours des spécificités mais toujours dans cet optique de standard, c'est au développeur de faire attention (lui il n'y est pour rien dans le respect des standards par les différents SGBD par contre il ce doit de connaître un minimum les spécificités de son SGBD face au standard).

3 : Pour le code de traitement, ca dépend ce que tu sous entends par ce terme. Si tu parles du code qui gère les entrées et sorties, si tu as un minimum modélisé, tu ne dois rien avoir à modifier.
Par contre pour reprendre ton exemple du choix entre un stockage BDD ou autre, hormis le faite qu'à la base quand tu écris une application du sais qu'elle en sera l'usage (j'ose l'espérer en tous cas), si par hasard tu souhaites modifier ce comportement, tu as le pattern 'Observateur' qui est la pour répondre à ce problème.
Je te r'envoi vers un tutorial que j'ai trouvé très bien fais et qui est un bon exemple d'utilisation : Observateur par Julien Pauli

Jedi PHP (Certifié Zend PHP) - Jedi MySQL (Certifié MySQL Core) - Padawan MySQL 5
Le côté obscur de la force bientôt rejoins ai-je ! :-°

`Haku

# Posté le 15/03/2008 17:25:55

**Rose**

"On" ne désignait pas ton tuto mais la majorité des textes.

1. Malheureusement, tout comme chaque moteur de rendu à sa façon, chaque SGBDR fait les choses à sa façon. Et en plus des disparités sur le standard, il faut compter avec les ajouts parfois très nombreux.

2. Et ce sont justement ces spécificités qui feront qu'on devra ré-étudier toute la base. Et à nouveau, le standard est loin d'être respecté.

3. Non, par code de traitement, je désigne ce qui utilise les données. Ce qui demande les données, ce qui dit qu'on doit sauver des données, etc. et qui prépare le contexte d'affichage.
Oui, je sais très bien quel sera l'usage de mon application, mais est-ce une raison pour la limiter alors qu'il est facile de lui offrir plus de souplesse ?
Toutes mes applications se décomposent en quatre couche :
- Couche contextuelle, elle se charge de préparer le contexte de l'application
- Couche de manipulation de données, elle se charge de renvoyer les données demandées sous des formes utilisables par PHP (array, objet, etc.) et des autres opérations (insertion, modifications, etc)
- Couche de traitement des données, elle se charge de traiter les données et d'utiliser les données pour préparer le contexte d'affichage
- Couche d'affichage, elle se charge d'afficher ce qu'il faut en fonction du contexte et des données
Avec PDO, les couches de manipulation et de traitement de données sont complètement mélangées, ce qui fait que les données sont obligées d'être dans une base de données. Il est totalement impossible de changer de système de stockage sans changer le code de traitement.
Moi, je sépare complètement des quatre couches. Ainsi, chacune d'elle est remplaçable car totalement séparées du reste. Et grâce à cela, si je veux utiliser des fichiers au lieu d'une base de données par exemple, j'ai juste à réécrire la couche de manipulation de données, tout le reste étant encore valide puisque séparé.

Envie d'apprendre le PHP ou le SQL ?
Envie d'en savoir plus sur le PHP ou le SQL ?
Suivez le guide...

JC Second

# Posté le 15/03/2008 20:13:21

Voir JAVA et mourir
Avatar

Groupe : Membres

J'ai lu ça en diagonale, je le mets dans un coin de ma tête pour un usage futur probable !

Une seule remarque : tu utilises le mot connection, c'est un anglicisme, le mot français est connexion.

Bon boulot à part ça

etaty

# Posté le 25/03/2008 11:18:43

Groupe : Membres

Merci pour le tuto
Pourrai tu expliquer la différence entre
http://www.siteduzero.com/tuto-3-24691-1-sql-en-poo-sans-prise-de-tete.html
et le tien
avantage, inconvénient ?

ps: 1000 excuses si tu l'a déjà fait

Draeli

# Posté le 25/03/2008 11:44:23

Groupe : Membres

Le lien auquel tu fais référence parle d'une autre librairie qui permet d'accéder au SGBD MySQL. Cependant je trouve que le titre n'est pas en relation avec le sujet traité (il faudrait que l'auteur mette plutôt : 'mysqli, librairie orienté objet, facilitons nous la vie').

Pour en revenir à ta question, dans le cas du lien auquel tu fais référence, il s'agit d'une librairie qui n'est dédié que pour le SGBD MySQL alors que PDO n'a que faire de savoir si derrière c'est MySQL, Oracle ou autre. Du coup, rien que pour ca, la différence est énorme et il vaudra mieux privilégier PDO (même si comme évoqué plus haut ca n'est pas la meilleur solution dans tous les cas, c'est la plus élégante proposé actuellement par les développeurs de PHP qui sont sans conteste plus à même de juger le meilleur équilibre des choix à faire).

Que ce soit mysqli ou PDO, dans les deux cas, il est tout à fais possible d'utiliser les avantages liés à la POO. L'avantage revenant à PDO pour les arguments présentés dans le tutoriel.

Donc dans le cas de mon tutoriel, ce qui a était présenté dans ton lien peut tout à fais être ré-implenté sous PDO. Pour cela tu peux reprendre comme base la classe présenté dans la partie 'Se faciliter la vie' qui te permettra sans te compliquer la vie de ré-écrire tout ou partie des méthodes (de PDO) et leur comportement (attention tous de même, car vouloir se faciliter la vie amène à devoir faire des choix sur l'orientation de l'application, sa lisibilitée, sa rapiditée, sa portabilitée, ... ).

Jedi PHP (Certifié Zend PHP) - Jedi MySQL (Certifié MySQL Core) - Padawan MySQL 5
Le côté obscur de la force bientôt rejoins ai-je ! :-°

etaty

# Posté le 25/03/2008 18:44:55

Groupe : Membres

Et niveau rapidité alors qui est devant ?

targuan

# Posté le 25/03/2008 20:05:50

on peut vivre sans
Avatar

Groupe : Membres

Pourquoi tu n'utilises pas l'héritage au lieu d'utiliser la méthode magique __call?
Quitte à surcharger la méthode PDO::query() puisque tu y apportes des modification.
Un truc du genreCode : PHP - Afficher / masquer les numéros de ligne

<?php
class taSQL extends PDO
{
private static $instance = NULL;
// can't be private
public function __construct()
{
include(CONF_DIR.'sql.php');
parent::__construct($dsn,$username,$passwd,$options);
}
/**
*
* @return taSQL
*/
public static function getInstance()
{
if(is_null(self::$instance))
{
$c = __CLASS__;
self::$instance = new $c;
}
return self::$instance;
}
public function query()
{
// query stuff
}
}

Ta méthode Bdd::flux devrait être en statique pour ne pas lever un erreur E_STRICT.

Certains diront que ça ne s'est pas passé comme ça.

Draeli

# Posté le 25/03/2008 20:44:27

Groupe : Membres

(Edit : Niveau rapidité, si quelqu'un a envie de s'amuser à faire les tests, je lui laisse volontier. Je considère que dans la mesure ou PDO devient le standard, la question de comparer ces deux librairies n'est pas d'actualité

)

Edit 2 : suite au bogue qu'on m'a remonté, j'ai fais sauter la dernière partie pour la ré-écrire

(et du coup je vais ajouter d'autres parties)

Jedi PHP (Certifié Zend PHP) - Jedi MySQL (Certifié MySQL Core) - Padawan MySQL 5
Le côté obscur de la force bientôt rejoins ai-je ! :-°

dijxdream

# Posté le 29/03/2008 22:56:22

Les Cons Servent Parfois...
Groupe : Membres

J'ai commencé à developper une toute petite libraire pour mon site que j'ai nommée DbSelector et que l'on pourrait apparenter à PDO dans le sens ou:
- elle est rédigée en PHP5 et donc orienté objet
- elle s'adapte à plusieurs SGBDR (DBMA en anglais).

Pour le moment, elle gère:
- PostgreSQL
- Oracle
- SQLite
- MySQL
Et leurs commandes de base, avec quelques fonctionnalités supplémentaires que je voulais voir apparaître sur mon site.

L'atout principal de ma Libraire par rapport à PDO est sa légèreté, et sa simplicité. Je dirais qu'elle ne fait pas tout -et elle n'est pas vouée à tout faire- mais ce qu'elle fait elle le fait bien. Si vous désirez la telecharger pour voir à quoi elle ressemble, c'est par ici:
http://apps.dijxdream.com/php/DB_SELECTOR/

Tout ça pour dire que j'ai bidouillé mon PHP pour mettre PDO sur les conseils d'un ami, et que je m'en veux. :-°

DijxDreaM: http://www.dijxdream.com/

etaty

# Posté le 03/04/2008 16:28:24

Groupe : Membres

On fait comment pour éliminer le while quand la réponse de la requête (query) ne fait que une seul ligne ?

edit: trouvé !
http://www.phpro.org/tutorials/Introduction-to-PHP-PDO.html#8.4

etaty

# Posté le 05/04/2008 13:02:31

Groupe : Membres

Desolé encore une question :lol:

(oui pdo me passionne)
D'après cette doc :PDO-quote
J'en déduit qu'il ne reste qu'une seule solution viable pour remplacer les mysql_real_escape_string()
Cette solution étant les requêtes préparées.

Es ce vrai ?

Draeli

# Posté le 05/04/2008 19:05:43

Groupe : Membres

La doc recommande en effet de les préférer (les requêtes préparés).

Maintenant de l'utilisation que j'en fais régulièrement, je serai tenté de te dire que : oui effectivement c'est potentiellement plus performant mais certaines requêtes ne marchent plus dés qu'on les passes en requêtes préparés.
Du coup par gain de temps, j'ai pris l'habitude de tous passer en quote ce que je sais être nécessaire (certaine chaînes étant déjà filtré en amont, généralement ca ce résume aux types string et 'date') et de laisser le reste en normal sans passer par une requête préparé. Dans l'absolu ca n'est peut-être par forcément le mieux mais je préfère passer du temps à optimiser une requête et gagner de précieuses secondes plutôt que d'avoir une requête lente et qui en plus risque de me claquer entre les doigts si je passe par une requête préparé (malgré tous le bien que je pense des requêtes préparés, pour l'instant je trouve ca mal foutu au niveau de la gestion PHP).

Edit : la méthode fetch si tu n'es sur d'avoir qu'un résultat en sorti et fetchAll si tu veux tous les résultats (1 à N)

Jedi PHP (Certifié Zend PHP) - Jedi MySQL (Certifié MySQL Core) - Padawan MySQL 5
Le côté obscur de la force bientôt rejoins ai-je ! :-°

etaty

# Posté le 24/05/2008 11:32:32

Groupe : Membres

de retour

Vaut t'il mieux faire une classe qui hérite de PDO
Code : PHP

<?php
class SQl extends PDO
{
   public function __construct($dsn, $username, $password, $driver_options)
   {
      parent::__construct($dsn, $username, $password, $driver);
   }
}
?>

Ou bien garder un lien en permanence dans la classe :
Code : PHP

<?php
class SQl
{
   private static $pdo = null;

   public function __construct($dsn, $username, $password, $driver_options)
   {
      self::$pdo = new PDO($dsn, $username, $password, $driver);
   }
}
?>