Bonjour à tous.

Après avoir fais une démonstration à mon prof et tuteur de stage, il à remarqué que j'utilise l'API Mysql.
Il m'a demandé qu'elles étaient les raisons de ce choix, et que selon lui l'utilisation d'un abstracteur de BDD, tel PDO ou Pear aurait pu être un plus pour la maintenir le code dans le temps. Il s'avère qu'il est vraiment avantageux de l'utiliser. Mais à ce stade du développement, je ne peux me permettre de effectuer des modifications qui pourraient nuire aux fonctionnement sachant que le délai de réalisation est quasi fini.
Mon prof m'a donc suggéré d'expliqué mes choix dans mes rapports, en analysant a postiori à défaut de l'avoir fais apriori.
Mais le problème est que je ne vois que des avantages à l'utilisation d'une abstraction, alors selon vous comment pourrais-je convaincre le jury de mon choix, y à t'il quelques problèmes, inconvénients auxquels je n'aurait pas penser et qui pourrait me donner des arguments valables?

Merci d'avance, Sbomb

Toutes les librairies d'abstraction n'implémente pas toutes les fonctions de tous les SGBD.
Par exemple dans PDO tu as rowCount() qui ne renvoie pas forcement une valeur correcte suivant le SGBD.
Le syntaxe SQL aussi est à considérer, chaque SGBD ne suit pas à 100% la norme et l'abstraction apporte donc la possibilité de plantage.
Car même si on change la chaîne de connexion et que derrière on utilise un driver différent dynamiquement, la chaîne SQL est en dure et donc pourra ne pas être interprétée correctement.

Un premier argument, assez convaincant effectivement, si quelqu'un peu aussi en apporter, ca pourrait franchement m'aider. Merci à toi.
J'accepte aussi à l'inverse qu'on me cite les gros avantage de l'API mysql, si il y en a.

Une couche d'abstraction en moins = plus de rapidité et de sécurité.
Mais bon dans le web la rapidité que j'entends est pas tellement prise en compte car c'est minime pour un tel traitement.
Par contre cela aurait son importance sur un système embarqué qui utiliserait une BDD au travers d'une interface d'abstraction.

Tu veux dire que passé par une couche d'abstraction tel que PDO perd en sécurité ou c'est l'inverse? J'ai pas bien compris, surtout que j'aurais penser l'inverse

Cela dépend de comment est pensé l'interface d'abstraction.
On peut penser que l'interface va implémenter sa propre sécurité qui pourrait rentrer en conflit avec celle du drivers appelé derrière.
Après si ce n'est qu'un pont vers le driver il n'y a pas de soucis.
Mais vu que PDO gère les requêtes préparées de façon logicielle par exemple ce n'est pas qu'un pont.
Mais tout dépend de la maturité de la librairie au final et surtout de la compétence de ses développeurs.

Mais encore là je pense que cela reste minime et que pour tomber sur un cas particulier d'erreur faut vraiment chercher...

Merci voila que c'est plus clair.
D'autre idée concernant d'éventuels inconvénients ?

Qui dit connexion dit duplicité de la connexion.
Tu peux très bien avoir plusieurs connexion à plusieurss sgbd, mais ce qui arrive le plus souvent plusieurs connexion sur le même serveur avec le même utilisateur et la c'est pas bien.
Avec PDO un suffit de l'étendre pour (single/|multi)ton pour éviter la cacophonie.
Mais cela a un inpact en terme performance (une classe de plus, me si ce n'est pas forcément de ce côté que l'on commencer à chercher si l'on souhaite maximiser les perfs) mais aussi et surtout un inpact sur la complexité du code (la gestion d'polling de connexion c'est pas forcément simple / voir utile).

Avec l'extension mysql généralement y a mysql_connect() bourrin au début du script et pis les autres fonctions se démerde (même dans des classes ou fonction vu que celle ci n'ont pas besoin d'avoir l'identifiant de connexion pour fonctionner.

Par contre c'est assez "crade" je trouve comme façon de faire.

Autre chose l'extension mysql n'est, il me semble, plus supportée (correction de bug) l'extension mysqli aurait était mieux vue (tu me dira un cherche mysql et remplacé par mysqli sur tout les fichier ça doit pas être l
Autre argument, si le code est entièrement procédurale c'est plus cohérent de continuer.

Portabilité de l'application sur les vieux server (php4), à ne pas utiliser si poo php 5 style

Sinon répondre simplement et franchement à la question (c'est pas forcément une tare)
- "ignorance" connais pas / sait pas utiliser => attention avec le net et les tonnes de tuto le ne sait c'est mis pour un dev, le premier aussi on devrait toujours être en "veille logiciel" doit au moins connaître.
- contrainte technique : c'était comme ça et pas le temps de corriger.
- t'aime pas la poo
- sûrement d'autre mais j'y pense pas

@+

Merci pour vos réponse, je vais mixer tout ca a ma sauce. A bientot et merci