Re: Piratage Mysql
On Sat, 17 Sep 2011 15:54:47 +0200, Aéris <aeris@imirhil.fr> wrote:
...
> Pour moi, une PS, c'est ni plus ni moins que du SQL enrobé dans une méthode.
> Si on commence à y intégrer du code métier, j'ai l'impression qu'on
> s'éloigne très fortement de l'objectif des PS.
Et c'est justement là que tu trompes: une PS ça *peut* être aussi simple qu'un
"SELECT col1,col2col3 FROM matable", mais c'est aussi et surtout capable de
beaucoup plus.
D'abord c'est écrit dans un langage structuré (SQL certes, mais aussi Pl/pgSQL,
Pl/Python, Pl/LUA, Pl/C, etc), c'est en prise +/- directe avec les données
(dépendant des droits d'exécution), mais c'est surtout intégré directement dans
la DB, donc ça dépend des mécanismes de contrôle de la DB qui
sont /sensiblement/ plus élaborés que ceux de php (au hasard).
Ca permet aussi de remplacer certaines VIEWs trop complexes à manier/modifier,
notamment en maintenance.
...
> Oui, ça d'accord, mais les PS sont quand même ultra-limitées…
Archi faux: il faut bien comprendre qu'une PS, c'est du code (et pas n'importe
lequel: primairement orienté DB).
> Elles ne supportent pas les arguments optionnels par exemple.
Encore archi faux: avec une PS on peut faire tout ce que l'on veut. Reste à
apprendre comment le faire ce qui n'est pas une mince affaire parce que
réflexion PGM ≠ réflexion DB.
J'ai mis presque une année à intégrer le fonctionnement, l'analyse et
l'application de tout ça à un résultat final parce que justement, même si ça
reste de la logique, elle est différent de celle de la programmation.
Ca n'est pas pour rien que les devs de gros projets sont complètement séparés
entre programmation et DB: ce ne sont pas les même métiers (un peu comme
Erlang est totalement alien à celui qui ne fait que du Basic).
> Comme je te l'ai mentionné, je ne vois pas comment on peut, via du PS,
> arriver à faire ce genre de trucs (pseudo-code, et non sécuritaire je le
> précise avant que ça n'hurle ^_^) :
> function getTopics ( string[] sortOrders ) {
> return "SELECT * FROM topics ORDER BY " + sortOrders.join(",");
> }
>
> Le fait d'avoir une requête SQL « dynamique » est pour moi en totale
> contradiction avec le fonctionnement même des SP. Ou en tout cas, je ne
> vois pas d'autres solutions que de faire :
> function getTopics ( string[] sortOrders ) {
> if sortOrders.is("date", "author")
> return callSPGetTopicsOrderByDateAndAuthor()
> else if sortOrders.is("date")
> return callSPGetTopicsOrderByDate()
> else if sortOrders.is("author")
> return callSPGetTopicsOrderByAuthor()
> else
> return callSPGetTopics()
> }
> On voit bien l'explosion exponentielle du nombre de SP…
Mais si on fait (tjrs en symbolique):
CASE 1:
RETURN SORTED BY Date
CASE 2:
RETURN SORTED BY Author
CASE 4:
RETURN SORTED BY Date AND Author
DEFAULT:
RAISE ERROR maPSamoi, "Illegal sort switch"
END CASE
on n'a plus qu'une seule PS.
> La seule solution que je puisse entrevoir serait de faire :
> function getTopics ( string[] sortOrders ) {
> return callSPGetTopicsGeneric(sortOrders)
> }
> ce qui reviendrait à faire descendre les contrôles de sécurité à la SP
> au lieu du PHP, et en plus je n'ose trop imaginer la tronche finale de
> la SP qui doit traiter TOUS les cas de requétage de l'application
> (ordres de tri, colonnes remontées, jointures possibles (bonjour la
> gestion de la sécurité avec les alias qui en découlent…), critères de
> sélections…).
D'abord il faut savoir si TOUS ces cas de tris ont une réelle légitimité...
Ensuite les contrôles de sécurité DOIVENT setrouver là où la sécurité est
justement maximale, en l'occurence dans la DB.
Et pour terminer, absolument rien n'empêche d'avoir une PS qui renvoie un set
de records qui elle-même appelle une autre PS pour effectuer un autre
traitement.
Encore une fois: OÙ est la différence avec du code php morcellé??
...
> Certes, le « SELECT * » n'est pas recommandé. Mais il a l'avantage de
> permettre d'être justement indépendant des SDD derrière : si je modifie
> ma table source, je n'ai pas à modifier ma requète !
> Le fait de limiter la clause SELECT :
> — bride l'application pour toute évolution future
> — demande X requètes/SP si j'ai la même « requête »-métier mais avec
> dans chaque cas un besoin de colonnes de sortie différent
C'est justement pour cela que j'appelle ça une erreur de débutant:
1- Rien dans les différents normatifs SQL ne garantie l'ordre de retour des
données (col1,col2,col3 ou col2,col3,col1 ou...) et c'est ce qui déconseille
formellement le '*',
2- Rien n'empêche d'avoir lesdites colonnes en paramètres de la PS,
3- À partir du moment où l'on a compris que la bonne syntaxe est de
nommer et ordonner les colonnes dans la requête, la maintenance d'un code
qu'il soit interne ou externe est strictement la même.
Encore une fois, c'est là que l'on voit les différences (profondes) entre
réflexion de programmation et réflexion DB.
...
> Il est plus facile de modifier un fichier de mapping de l'ORM / modifier
> ma classe de DAO / grepper dans mes fichiers PHP (dans l'ordre de
> préférence) que de grepper dans une foultitude de SP.
Dans l'état actuel des choses, un ORM est une ineptie - tout au plus peut il
servir lors d'une phase de mise au point.
Pourquoi en rajouter une couche (qui ralentit fortement l'ensemble) alors
qu'une bonne conception évite cela??
> Surtout que supprimer un champ dans une SP, ça va encore, « grep » le
> verra. Mais difficile de grepper un champ qui n'existe pas encore parce
> qu'on veut l'ajouter.
Comme dit plus haut, il suffit qu'il soit donné en parm à la PS.
> Et quid de la difficulté de s'assurer que les SP du serveur sont bien
> celles attendues pour la version X, et pas celles de la version X-N ?
Là, je ne veux pas être méchant mais si tu distribues une MàJ du code php sans
celle de la DB, faut changer de métier tout de suite: c'est un tout.
> > Dans ce cas (comme dans les autres), il *FAUT* faire signer au client un
> > cahier des charges exhaustif
>
> Le cahier des charges était exhaustif pour chaque version.
> On parle bien d'évolutions plusieurs mois après la mise en production.
Les prospectives AUSSI doivent être évoquées - et cela à tous les niveaux: que
cela soit avec les informaticiens locaux, les utilisateurs, les cadres et les
décideurs; c'est la seule façon d'obtenir une vue d'ensemble de la chose et
d'éviter les télescopages entre les désirs des uns et les impératifs des
autres.
Ca évite une bonne partie des mauvaises surprises futures.
> Dans mon cas, il s'agissait d'un système de gestion de transactions
> bancaires et l'évolution consistait à ajouter de nouveaux critères de
> calcul (en gros des champs dans les tables, et là on a pleuré de ne pas
> avoir mis de « SELECT * »…)
V. plus haut.
Et dans une PS, il est excessivement facile de renvoyer un champ calculé (pour
peu, bien sûr, qu'on ait les bonnes colonnes déjà existantes).
> > - ET avant tout se rappeler qu'un pro a le DEVOIR
> > (juridique!) de dire non à son client si ses desiderati sont farfelus.
>
> À l'instant T0 de la signature du contrat, ils n'étaient pas farfelus.
> À l'instant T0+18mois et 500 SP plus tard, ça l'est devenu un peu plus…
Là il ne peut y avoir que 2 poss: soit l'analyse a été mal faite, soit le
client n'a pas été clair (voire un peu des 2).
Pour ce qui est de la clarté, un client c'est comme un clébard: ça s'éduque;
une façon simple de faire est de lui expliquer que ce que LUI considère comme
une modif triviale peut prendre une semaine de boulot, alors que ce qu'il
considère comme extrêmement compliqué peut dès fois être réalisé en moins
d'une heure.
Mais dans le cas présent, je soupçonne fortement (et à priori) un défaut de
conception de la DB.
> > 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...
>
> Cas classique, mais à la réponse à un appel d'offre et avant la
> signature du contrat, il est souvent difficile de voir tous les futurs
> points de blocage, d'autant plus que le client se gardera bien de te
> signaler ceux qu'il a déjà anticipés,
Les clauses réservatives sont là pour ça, d'ailleurs un contrat sur appel
d'offre ne devrait *jamais* être signé sans l'approbation d'un cabinet
d'avocat spécialisé.
> et que toi tu es pressé par les délais (4 jours pour répondre à un appel
> d'offre de 1.000 pages).
Et pourquoi pas 24H tant qu'on y est!?
Si vous répondez à n'importe quoi en 6 secondes 22 il ne faut pas venir se
lamenter après que le client n'a pas dit çi ou ça.
...
> > Explique-moi la diff que tu vois entre entre des morceaux de php et
> > différentes PS?
>
> Physiquement parlant, il n'y en a aucune, tout n'est que fichiers au final.
> « Métièrement » parlant, un monde sépare les 2, d'autant plus si on sort
> du monde PHP.
> Je peux par exemple m'appuyer sur la POO (héritage, polymorphisme,
> généricité, abstraction…) pour limiter la duplication, centraliser
> l'information, factoriser mon code…
O_o tu fais de la POO en php...
> Un exemple à la con : il y a de fortes chances pour que le nom de mes
> tables se trouvent à un seul endroit dans mon code, quand chaque SP
> devra dupliquer l'information. Idem si j'ai 2 requêtes « identiques mais
> pas tout à fait », fortes chances d'arriver à factoriser tout ça au
> niveau code quand les SP feront un gros copié/collé de derrière les fagots.
Et si le nom de la table n'était qu'un parm d'appel de la PS?
Voila une idée qu'elle est bonne! (et qu'elle permet de réutiliser la PS avec
d'autres tables).
> > Dans mon système, le MVC n'existe pas (en fait c'est la PS qui a ce rôle).
>
> J'ai toujours du mal à voir comment.
> Le but du MVC est d'obtenir une page quasi-HTML (ie. débarrasée de toute
> présence de code métier) d'un côté et toute la récupération des données
> de l'autre, de séparer la forme et le contenu en somme.
> SP ou pas, ça n'a pas de rapport, ça ne reste que la partie M du MVC
> (qui est ma DAO en JEE par exemple), il te manque encore toute la partie
> C et V
Quelle est la différence entre mettre en page du code qui vient d'une requête
en php et celui qui vient d'une PS; perso, j'vois pas (partie V).
Pour la partie C, elle est aussi incluse dans la PS.
> > 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.
>
> Ça se prête généralement pas trop mal à tout type d'application.
> Le gros avantage du N-tiers est de permettre des évolutions (métier,
> physique ou technique) très faciles.
> Je change de moteur de base sans rien faire. Je remplace ma DAO JPA par
> une couche web-service ou tes SP en 10min. Je scallabilise ma couche
> service en 30 min.
Moi aussi j'aime bien les Lego, mais c'est pas avec ça que je construirais ma
baraque...
Plus sérieusement, ces outils ont été développés pour des raisons et des
besoins particuliers, PAS pour être mis à toutes les sauces.
Chaque outil a ses propres spécificités; par exemple tu peux faire tout ce que
tu veux en N-tiers en matière de communications, mais je te mettrais toujours
une pallée en utilisant Erlang et en scalant mon système en 3 lignes de code
sur un nombre illimité de nodes en qq secondes.
La bonne question c'est: est-ce qu'utiliser ceci ou cela apporte vraiment de
l'eau au moulin ou est-ce juste un pis aller pour aller plus vite (en Gal au
détriment de l'évolution).
Un tout ch'tit exemple: tu dis "Je change de moteur de base sans rien faire"
sauf que chaque DB a certaines spécifités et que certaines, même hors normes
SQL, facilitent grandement la vie.
Un autre: ça ne me viendrait même pas à l'esprit ne serait-ce qu'envisager
d'éventuellement un jour peut-être de penser à mysql pour une appli sérieuse.
> > 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.
>
> Certes, mais en même temps, quand tu tapes dans une table de 2To, pas
> sûr que le temps de chargement du navigateur soit celui à prendre en
> compte =)
Quand bien même la table ferait 2T *rows*, c'est juste une question de
conception correcte de la DB, de ses indexes, de ses PS et de ses requêtes
(considérant que le hard a été au préalable correctement dimensionné).
--
Is this really happening?
Reply to: