Re: Piratage Mysql
On Sat, 17 Sep 2011 12:52:59 +0200, Aéris <aeris@imirhil.fr> wrote:
...
> Je serais intéressé par un exemple, là comme ça je ne vois pas…
Bien essayé, mais pas tant que je n'ai pas fini et publié mon projet.
> Comment peut-on gérer par procédure stockée le fait que les arguments
> peuvent être variable (tri par date *OU* par nom), avoir des
> comportements différents (nombre de post dans un topic, puis liste des
> topics, puis liste des posts du topic joint avec la table des auteurs),
> ou retourner des valeurs différentes (dans les cas précédents, un
> nombre, une liste de topic, une liste de (post + auteur)) ?
> Sans exponentiation du nombre de stored-proc et/ou de leur complexité,
> j'ai du mal à concevoir…
C'est pourtant relativement simple: ce que tu faisais dans php tu le fais
maintenant dans la PS, avec juste qq lignes de plus pour gérer ce type
d'indirection.
> > de l'autre on gagne une malléabilité énorme et l'abstraction par rapport
> > aux données;
>
> Là aussi, je bloque…
Les données sont totalement inaccessibles de l'extérieur sauf pour le SU de la
DB; seules les PS y ont accès, après contrôle des droits de l'appelant.
> À la moindre modif des fonctionnalitées et/ou de la structure de
> données, j'imagine assez mal comment on peut éviter un refactoring
> monstrueux du nombre tout aussi monstrueux des stored-proc.
Non, le travail est égal, à moins bien sûr que tu n'utilise des trucs de
débutants comme SELECT * FROM matable au lieu de SELECT col1,col2,col6 FROM
matable.
> Par exemple avec l'exemple des topics précédents, le fait de rajouter
> une date de publication à un post par exemple, nécessite a minima
> d'ajouter encore X stored-procs pour pouvoir gérer les filtres et les
> tris sur cette colonne, de refondre Y stored-procs pour ajouter cette
> date en données de sortie, etc.
Pas plus que dans du code extérieur.
> > La maintenance n'est pas plus lourde que pour un pgm en php, voire plus
> > légère,
>
> Si on arrive à m'expliquer les points ci-dessus, OK, pourquoi pas…
> Pour l'avoir déjà expérimenté sur un projet où la contrainte cliente
> était de n'avoir aucune requête dans le code mais tout dans les
> stored-procs, ça a été un échec total déjà sur la 1ère version du soft
> (de mémoire, on manipulait plus de 500 SP), et un cuisant Armageddon le
> jour où on a du refondre les fonctionnalités et les données.
Dans ce cas (comme dans les autres), il *FAUT* faire signer au client un
cahier des charges exhaustif - ET avant tout se rappeler qu'un pro a le DEVOIR
(juridique!) de dire non à son client si ses desiderati sont farfelus.
J'ai souvenir d'un ami a qui le commercial a refilé un dossier; après (courte)
analyse ce que voulait principalement le client se résumait à 30,000 hits à la
seconde...
> >> > De toutes les
> >> > variantes de paramètres et/ou de sorties différentes ?
> > Non: il est relativement aisé d'écrire une proc polymorphe qui ne retourne
> > que les colonnes autorisées (ou renvoie une erreur si pas d'autorisation).
>
> Cf questions ci-dessus. J'ai du mal à me faire une idée de l'existence
> de telles SP.
Ca m'a pris un temps fou en travail et réflexion pour trouver des solutions;
donc comme dit plus haut, pas de comm tant que mon projet n'est pas
terminé/publié (ce qui prendra le même temps... que le fût du canon pour
refroidir:).
> > Pas plus que des centaines de petits morceaux de code d'un pgm en php,
> > voire même moins puisque chaque proc a une fonction bien déterminée
> > (quitte à avoir un peu de redondance dans le code afin d'éviter le
> > morcellement).
>
> Et donc à balayer d'un revers de la main toutes les bonnes pratiques de
> développement…
Explique-moi la diff que tu vois entre entre des morceaux de php et
différentes PS?
> > Je ne comprends pas ta vue de la chose: quelle différence vois-tu entre
> > greper dans des centaines de bouts de code php pour s'y retrouver et
> > modifier ces morceaux comme voulu, et modifier directement une ou des
> > procs stockées dans la DB?
>
> En PHP, je ne dis pas, mais même dans ce langage, un programme « bien
> conçu » (3-tiers, MVC, template, séparation forme/contenu…) est assez
> facilement maintenable et évolutif.
Dans mon système, le MVC n'existe pas (en fait c'est la PS qui a ce rôle).
Par ailleurs je reste persuadé que l'archi 3-tiers est très loin d'être une
panacée universelle; contrairement à ce que pense notamment la plupart des
programmeurs, notamment web.
Le 3-tiers est utile dans certains types d'applis bien particulières, pas dans
toutes.
C'est comme pour les sites qui mettent 3' à charger la page de garde, ça n'est
pas parce qu'on a un quadri-CPU en dev qu'on ne doit pas penser à ceux qui
surfent avec un P3-500 - beaucoup, si ce n'est la plupart, devraient bien se
rentrer cela dans la tête.
> > À part les langages différents et surtout le fait que le contrôle total
> > des données soit dévolu à la DB et non-plus à du code externe, je ne vois
> > pas où se trouve le différentiel de maintenance.
>
> Il se trouve aussi du côté des outils.
> Si je développe en Java, j'ai des outils de refacto automatique, de la
> complétion automatique, des navigateurs de code…
> Choses déjà passablement existantes en PHP (mais c'est possible) mais
> carrément inexistantes au niveau BDD et SP.
Il existe des tas d'éditeurs permettant une personnalisation poussée.
Par ailleurs je me suis aperçu que la phase de conception est très souvent le
parent pauvre de la programmation; c'est une erreur: quand tu as bien pensé ta
proc il ne te faut que très peu de temps pour la transformer en code
opérationnel.
Evidemment, cela va à l'encontre de la mode actuelle où il faut pisser de la
ligne de code au kilomètre et où bien souvent on ne se pose la bonne question
que trop tard.
Rappelle-toi d'ailleurs (enquête sur une douzaine de SSII il y a qq années) que
60% des actions nécessitent un retour chez le client pour non-conformité/bugs/
mauvaise ergonomie/etc (mes propres informateurs me rapportent plutôt un %age
proche de 85%).
Je ne prétend pas avoir la science infuse, très loin de là, mais s'il y a une
chose pour laquelle je suis doué c'est de repérer les erreurs que font les
autres, et par voie de conséquence tâcher de ne pas les répéter.
--
Nadia Comaneci, simple perfection.
-- '76 Olympics
Reply to: