Re: Piratage Mysql
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 17/09/2011 17:50, Jean-Yves F. Barbier a écrit :
> 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).
OK, mais on sort totalement du cadre des procédures stockées lambda…
Et entre mettre du code dans la db ou du code dans l'appli, pour moi
c'est du pareil au même, et sauf à demander 2× plus de travail et de
personnes, je n'en vois pas l'intérêt.
Bien que je ne maîtrise pas ce que permet de telles SP au niveau
sécurité DB, j'imagine assez mal ne pas pouvoir faire ce type de
contrôle au niveau applicatif. Peut-être me trompé-je…
Et qui dit 2 sources de code dit 2× plus de risque d'erreur !
> Ca permet aussi de remplacer certaines VIEWs trop complexes à manier/modifier,
> notamment en maintenance.
Là je te suis parfaitement, c'est d'ailleurs une des utilisations que
j'en ai, avec le traitement de procédures trop longues ou inefficaces
côté applicatif.
> 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.
Gros problème que j'y vois : cette manière de penser (que j'imagine bien
loin de tout standard SQL et reposant sur des API propres au moteur
utilisé), est totalement non portable, réutilisable ou généralisable.
Tu changes de moteur, ton année de travail aura été totalement vain.
> 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).
Euh, sur de gros projets, les DBA s'occupent de la structuration des
données (schémas, indexes, configuration et paramétrage du moteur…), pas
du développement…
>
> 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.
C'est effectivement la solution que j'envisageait.
Mais dans une application classique, je pense que N tend plus vers 200
que vers 5…
> D'abord il faut savoir si TOUS ces cas de tris ont une réelle légitimité...
Dans une application « classique », oui.
Par exemple dans les écrans de reporting et/ou de traçabilité.
> Ensuite les contrôles de sécurité DOIVENT setrouver là où la sécurité est
> justement maximale, en l'occurence dans la DB.
Pas convaincu…
J'ai l'exemple d'une de mes applis de gestion biométriques où les
données nominatives n'étaient accessibles que par les admins du système.
Une partie du contrôle des accès aux colonnes de la db était donc à
faire au niveau applicatif !
> 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 '*',
C'est pour ça que je n'utilise pas le positionnel, mais bien les champs
nommés.
> 2- Rien n'empêche d'avoir lesdites colonnes en paramètres de la PS,
Ce qui ouvre la voie à de l'injection SQL ? =)
> 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.
+1 aussi là, mais pas de rapport avec les 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??
Un ORM, c'est pas juste un bidule qui te connecte à la base…
Ça t'apporte pas mal d'autres choses, comme les pools de connexion, les
caches multi-niveaux, l'indépendance du moteur…
Par exemple avec Hibernate, je vais utiliser à plein les principes de
localité temporelle et spatiale et économiser un maximum de requêtes
superflues grâce aux caches.
> 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.
Si le monde était aussi rose, ça se saurait depuis longtemps =)
Et je peux très facilement vérifier que mon client a exactement les
mêmes fichiers que moi en production (MD5), il en est autrement pour les
SP potentielles sur le moteur…
> 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.
Un client a souvent du mal à définir son futur, surtout à 18 ou 30 mois.
J'ai même dans mon entreprise des demandes d'évolution sur du soft de 30
ans d'âge !
> 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).
Non, juste que tout faire en SP ne nous semblait pas impossible
techniquement, et reste d'ailleurs même encore aujourd'hui complètement
faisable.
Le soucis est venu au cours du développement, quand on a commencé à voir
le nombre de SP, avec X variantes de la même requête, mais avec plus ou
moins de données sortantes, de critères de sélection ou de tri…
Les développeurs s'arrachaient la tête pour savoir si une fonctionnalité
avait déjà été SPifié ou si le travail restait à faire, pour trouver
telle SP qui devait être corrigée, ainsi que toutes ses variations
potentielles.
> Mais dans le cas présent, je soupçonne fortement (et à priori) un défaut de
> conception de la DB.
C'était le cas en partie, mais la base avait été héritée d'un ancien
système et on ne pouvait pas trop y toucher.
Et pour achever le coup des SP, la plupart des requêtes étaient
dépendantes d'un fichier de conf (XML) qui définissaient les règles
métiers (répartition fonction du client, taxes variables, frais,
ristournes commerciales…).
Le nombre de paramètres à passer aux SPs étaient effroyables (jusqu'à
300 paramètres pour la plus grosse de mémoire).
> 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é.
Les clauses sont là, mais rarement appliquées.
>> 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.
>
> O_o tu fais de la POO en php...
Heureusement que j'ai bien précisé « d'autant plus si on sort du monde PHP »
> 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).
Et de redescendre l'injection SQL un poil plus bas…
> 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).
Aucune, c'est bien pour ça que à V identique (template, JSP…), c'est
uniquement le M qui différera (JPA dans mon cas, SP dans le tient).
Et donc la V n'a *RIEN À FAIRE* dans le moteur.
Pire, c'est même contraire à la philosophie MVC qui stipule qu'on doit
pouvoir changer de vue voire en avoir plusieurs pour un même M.
Si demain je veux mettre des web-services ou faire une appli lourde au
lieu de mon appli web, je n'ai théoriquement que le V à changer et un
peu le C, le M reste *STRICTEMENT* le même.
> Pour la partie C, elle est aussi incluse dans la PS.
Gné ?
Ça devient limite de l'hérésie là…
Le jour où je rajoute des écrans, je dois toucher à ma BdD ? Oo
> 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.
Certes, mais qui pourra maintenir ton code derrière ?
Non pas que je défende qu'on doit pouvoir refiler la reprise de code au
premier venu, mais à l'inverse, s'il faut que la recrue mette la même
année que toi à comprendre le langage / système…
> 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).
Oui, à long terme.
On sait d'avance que les évolutions seront nombreuses (surtout dans mon
domaine principal, l'industrie), et les équipes très fluctuantes (SSII).
Le soft se doit d'être abordable tout en étant suffisamment bien gaulé.
> 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.
C'est pour ça que Hibernate définit la notion de dialecte et se base sur
les API propres à chaque moteur (non pas comme certains le pense en se
conformant à la stricte norme SQL).
Il utilisera par exemple les serial et séquences de PostgreSQL au lieu
de l'auto-incrément MySQL.
> 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 bien pour ça que je l'ai fait bannir de notre bureau d'études.
Comme remplaçant, PostgreSQL !
> 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é).
Oui, et ça c'est le taff du DBA.
Mais même tout ça bien calibré, les millisecondes de latence du
navigateur seront pinuts comparées à la bonne grosse seconde de calcul…
- --
Aeris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJOdN6TAAoJEK8zQvxDY4P93NUH/ieps2F58INYIuaVPfXYq5FR
fCETFxK2xY0HXnI3BJ54/0iXpRhC4dMvrZAME6dJjpqT6ssercedH8YIrDUO5sEp
poy0FvAf/+WnGf4qymLbQYWaePW/0EcEYvL3mJQhgURnqnwXaEguSkKkVOZk7yuQ
h+2wTNIwXEWqNR4qG1o7rYUJZJS4Rnz+iRZG+KG02Zj+L1Ym3Tivg8cVOQRFIw+P
re5Jtq0LONBlyLmWsiAizcMP30hq6xCPx4ohft/ldaHx6hJYE8oY9boo4S4TbFip
I6ebU19hwGpdN6+oXBjMJGq84nprKGV6S8KocdhSzK/JHbV4lsgSTyj9x60D/Aw=
=Cf4T
-----END PGP SIGNATURE-----
Reply to: