PHP|Débutant :: Forums

Bonjour,

Merci pour ton retour MK. Tu as parfaitement raison, Mon raccourci était un peu trop raccourci^^; je viens d'ailleurs de rectifier sur mon post pour l'essentiel.

[MK]Ok, du coup je vire mon post qui pollue désormais inutilement ce sujet.[/MK]

Suite à la demande justifiée de MK, voici quelques explications sur le code fourni.

- Concernant le DELIMITER, il sert à délimiter les deux fonctions contrairement au ; qui sert à délimiter les instructions. Le DELIMITER par défaut est le ; ce qui oblige à le changer pour pouvoir définir deux procédures/fonctions différentes dans la même "action" ou portée de code. Ainsi il est inutile d'en définir un à la fin au même titre que l'on en aurait pas mis si une seule fonction avait été définie.

- Maintenant voici un exemple d'application. Pour l'exemple je vais limiter une création de CLIENT à une table de 2 champs + clé primaire. On peut à partir de là aisément l'étendre à plus de colonnes, évitez d'ailleurs un trop grand nombre de colonnes et privilégiez des structures à moins de 20 colonnes à chaque fois que cela vous est possible. Pourquoi j'ai pris dans mon exemple initial une chaîne de 30 paramètres? Cela ne signifie aucunement que ma table client possède 30 colonnes mais que la procédure de création d'un CLIENT (utilisant plusieurs tables) nécéssite une trentaine de paramètres.

Imaginons que ces 30 paramètres sont utilisés dans une procédure de 3 requêtes utilisant chacune 10 paramètres. C'est un peu contraignant par rapport à PHP certes, mais il va falloir passer ces paramètres dans des variables locales, soit via un DECLARE soit via une variable utilisateur, locale elle aussi, avec le préfixe @. Pourquoi? simplement pour optimiser la longueur de code et les ressources utilisées si l'on a besoin d'effectuer un ou des traitements sur le paramètre (vérification,etc...) avant de le passer dans la requête. Tout comme dans une table normalisée le type de chaque variable doit être optimisée en fonction du paramètre.
Admettons donc que le caractère de séparation de champs soit la virgule on récupérera chaque paramètre de la façon suivante

Voilà donc l'utilisation du code.

PS: Vous noterez que j'ai parlé de traitement de vérifications de chaque paramètre avant de les passer dans leur requêtes respectives. Ceci est fondamental et ne doit pas être négligé car il en va de la qualité de vos données et de leur intégrité. Vous ne pouvez pas vous permettre de vous en remettre au code applicatif pour valider les paramètres passés à votre procédure, au même titre que vous ne devez pas le faire entre deux fonctions PHP.

++

Dernière modification par Jc (15-07-2013 17:16:10)

Bonjour,

Les contextes d'appel de création de ligne (vulgairement enregistrement) en php sont au nombre de deux.

1) Via un formulaire de saisie HTML envoyé à une page PHP de traitement en GET ou POST
Rien de plus classique

Deux choses importantes à dire à ce niveau
- Pas besoin de créer un contexte transactionné au niveau de PDO, cela doit être fait au niveau de votre procédure dans le SGBDR.
- Si votre procédure stockée gère les erreurs avec l'instruction SIGNAL de la version 5.5 de MySQL, et que votre procédure retourne une erreur, l'erreur doit être récupérée via le gestionnaire d'erreur de PDO.

2) Via une requête Ajax
La chaine de paramètre peut être construite directement au niveau du javascript et transmise à PHP via JSON ou normalement ou chaque paramètre peut être transmis à php indépendament les uns des autres (même cas de gestion que précédemment).
Si les paramètres sont transmis en JSON par exemple un simple

suffit.

Et voila, la délégation de la gestion des données passe du côté SGBDR. Vous pouvez donc vous consacrer coté PHP et client à la gestion de votre interface et des interactions utilisateurs pleinement.

Dernière modification par Jc (15-07-2013 17:16:45)

Yop,

pourquoi addslashes ?

Alors que PDO propose la méthode quote

Le coté rappel d'utilisation de mysql (fonction, proc stock, validation sur le SGBDR) est sympa, c'est vrai que l'on vois rarement ce genre de chose dans les tutos.
Par contre je trouve que ce type de fonctionnement, perd la lisibilité du code et impose un traitement en plus.

le coté perf, je connais pas, et je reste étonné

heu c'est le role d'un sgbd dans une appli n-tiers, ou je n'ai pas compris le sens de la phrase :s
La validation des données étant, bien sur a réaliser aussi sur le SGBDR (et la gestion d'intégrité si besoin) peut être est ce que tu entend par la.

@+

Tiens, Ranuleto, toujours vivant ?

Puisque Jc n'est pas présent, pour le moment, je vais répondre, en partie, à tes objections.

Pour PDO::quote, tant qu'à faire, je préconiserais PDO::prepare et PDOStatement::execute

Je laisse à Jc le soin de justifier éventuellement le recours à addslashes.

C'est une partie de son rôle, mais une partie seulement. La notion de SGBD épais, embarque l'idée que tout ce qui peut utilement être fait par le SGBD doit lui être confié.
Ça va un peu à l'encontre d'un des dogmes de la conduite des projets des années 80 (séparer les données des traitements) mais ce n'est pas un retour en arrière, ce ne sont plus les données qui sont intégrées dans les traitements (cf la DATA DIVIVION du CØBØL), mais certains traitements qui sont confiés au SGBD.

Quant à la lisibilité du code, c'est là un vaste débat.
Je préfère, et de loin, le recours à des procédures stockées que l'utilisation d'un SGBD pour y stocker des pages HTML ou des scripts PHP ou d'autres langages.
Personnellement, j'ai, par exemple, quelques difficultés conceptuelles pour concilier un SGBD épais avec un pattern comme MVC (Modèle, Vue, Contrôleur), mais mes limites ne sauraient constituer un critère suffisant pour rejeter cette approche ô combien prometteuse.

Ah j'ai oublié une chose.

Concernant ta réponse MK à utiliser une requête préparée au lieu de QUOTE() ou $myPDO->quote() je suis en désacord avec toi sur le principe d'utiliser une requête préparée sous seul prétexte d'éviter les problèmes d'injection SQL. En effet l'intérêt primaire d'une requête préparée est de pouvoir effectuer une même requête effectuée de multiples fois avec des paramètres différents. Or si un seul traitement est nécessaire la requête préparée perd de son sens car elle est moins performante pour une seule requête que son équivalente non préparée.

Puisque toutefois l'objet de ce post est le développement en SGBDR épais, il y a une exception à ce que je viens de dire dans un contexte de procédure stockée sous MySQL et dû essentiellement aux limitations de MySQL, limitations qui n'existent pas au sein d'un vrai SGBDR comme SQL Server ou dans une moindre mesure postgreSQL.

Je m'explique.
Une requête préparée est une requête qualifiée communément comme requête dynamique car les paramètres passées à la requête sont définies par des variables. En d'autres termes on ne connait  la valeur des variables passées à la requête qu'au moment de l'éxécution.
Ceci étant dit, une requête statique (dont tous les éléments sont connus et fixés à l'écriture du code) peut être construite dynamiquement ne serait-ce que pour éviter de créer une procédure stockée par requête de traitement. Il se trouve qu'une telle requête est appelée et considérée à tort comme une requête dynamique. Vous trouverez un exemple sur ce forum dans ce post. Or, pour éxécuter une telle requête dans une procédure stockée mySQL, et bien qu'elle soit statique, on est obligé de passer par une requête préparée dans mySQL.
Il faut savoir qu'utiliser une requête préparée dans mySQL entraine une limitation importante qui est l'impossibilité d'utiliser un curseur. Par conséquent si votre requête retourne plusieurs lignes vous serez obligé de passer par une concaténation de lignes par colonne avec GROUP_CONCAT pour pouvoir les traiter (utiliser les 2 fonctions données dans l'introduction pour pouvoir parser les résultats et appliquer les bons traitements).

++

Dernière modification par Jc (07-05-2012 20:12:09)

Ce n'est pas tout à fait exact, disons, que c'est mal exprimé.
Les paramètres sont les mêmes, ce sont leurs valeurs qui peuvent changer d'un appel à l'autre de la requête.

Ceci dit, je n'ai pas d'avis tranché sur le sujet, par une sorte de psittacisme, je ne faisais que relayé les préconisations de la doc MySQL.

Vu que j'ai posté mon message à

que je l'ai modifié à

et que tu as posté ton message

quand tu as dit que tu es lent, je pense que c'est un doux euphémisme sacré MK