Re: Piratage Mysql
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le samedi 17 septembre 2011 22:41:42, vous avez écrit :
>> 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…
>
> Avec l'apparition de Pg ≥ 9.0 le contrôle est devenu bcp plus fin
> (colonnes), il me parait donc logique que la DB s'occupe du contrôle
> d'accès.
Oui et non.
Cf un peu plus loin.
> C'est en partie vrai, mais depuis qq temps on observe une
> convergence, à mon avis non-fortuite, entre Pg & Oracle; et il n'y a
> pas tant que cela d'autres compétiteurs du même niveau. C'est pour
> cela que j'essaye de penser hors des sentiers battus; la portabilité
> c'est Tbien dans l'abstrait, mais encore faut-il: * qu'il y ait un
> intérêt quelconque à éventuellement switcher,
J'en vois même un tous les jours, et un énorme :
– Mes tests U tournent sur une db H2, ce qui permet de lancer les tests
sans trop se soucier de l'environnement et donc de rester « unitaire »
et non « intégration »
— Ma prod tourne sur une db PostgreSQL
Le tout en ne changeant qu'un seul fichier de conf (et plus exactement 2
lignes de XML, le driver et l'URL de connexion), et rien au niveau du code.
> * qu'il existe un moteur capable de rendre les même services.
Oui et non.
Ça ne sera pas forcément exactement les mêmes services, mais le même
résultat, Hibernate se chargeant de convertir mon besoin en appel natif
à la base, fonction du moteur qu'il y a derrière.
> * que ladite portabilité ne se fasse pas au détriment des perfs.
Pas remarqué en tout cas.
Même mieux, Hibernate soulage énormément la bd, en cachant les requêtes.
1 SELECT + N UPDATE + 1 DELETE génèrera uniquement 2 requètes en base,
le SELECT et le DELETE, les UPDATE étant inutiles…
Idem avec les phénomènes de cache, N SELECT conduiront à 1 seul SELECT
réel, les autres tapant directement dans le cache.
J'ai même déjà vu des systèmes avec une RAM suffisamment dimensionnée
parvenir à plus ou moins 0 requête SQL (une de temps en temps en cas de
défaut de cache).
> Même si N=300 ça ne pose pas de PB insoluble (surtout que dans Pg,
> une
fois
> passé le premier appel qui déclenche la compilation, c'est le
> pseudo-code qui est exécuté).
Certes, mais 300 cas centralisés dans 1 seule SP (sachant que le maximum
toléré en développement normal est 10), c'est de l'hérésie et ça pue à
plein nez le truc inmaintenable…
>> 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 !
>
> Développe un peu plus parce que là je ne vois pas le tableau.
L'application en question gére la délivrance de passports biométriques.
Les champs nominatifs de la base (nom, prénom, adresse, n° sécu…) sont
accessibles uniquement aux administrateurs et aux experts biométries,
pour des raisons légales (style la CNIL chez nous).
Les personnes lambda n'ont accès qu'aux données banalisées (n°
d'enregistrement, bureau d'enregistrement…).
> Ca n'est point ce que j'avions lû qq posts plus haut, gent
> damoiseau!: "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 !"
> SIC
Oui, et je maintiens mes propos.
Je peux faire un « SELECT * » mais accéder aux données par un «
row['col1'] » au lieu de « row[0] ».
En PHP, c'est la différence entre « fetch_row » et « fetch_assoc ».
Au final, je conserve un code évolutif (l'ajout de colonne ne perturbent
pas mon code), sans avoir de problème d'ordre.
Avec Hibernate, c'est encore plus simple, parce qu'il génère tout seul
la liste des colonnes qui l'intéresse !
En gérant celle en lazy-loading, etc…
> Si j'ai besoin de pools et/ou de cache(s), je vais les chercher
> individuellement là où ils sont 100% fonctionnels et très
> performants, pas dans une soupe où l'on trouve tout et n'importe
> quoi - souvent bricolés à la va-vite sur demande pressante des
> utilisateurs.
Hibernate est basé sur des caches et des pools éprouvés.
Et qui n'ont pas été développés exclusivement pour lui.
Citons par exemple :
— Caches : EHCache, JBoss Cache, Oracle Coherence…
— Pools : C3P0
> Apparemment mauvaise analyse dûe à une connaissance pas assez
> approfondie de la DB utilisée.
Non, juste que la base avait des tables à plus de 400 colonnes, et des
critères de filtres sur 100 ou 150 critères.
> Dans ce cas, fais les passer en AGILE ou XP - je ne sais plus lequel
> procède par releases rapides, mais c'est un système qui a bcp
> d'avantages: release when ready AND tested, puis ajouts de
> fonctionnalités par releases, jusqu'à release 1.0
Le soucis n'était pas d'ajouter de nouvelles fonctionnalités, mais de
savoir dans le détail comment les SP étaient gaulées, afin de limiter
les duplications, de cerner les régressions possibles…
Quand tu as des centaines de SP devant toi et que tu dois implémenter «
chercher les X qui contiennent Y et les trier par Z », t'as 2 solutions :
— soit tu passes du temps à dépiauter tes SP dans tous les sens pour
voir si une ne ferait pas déjà les ¾ du boulot (du genre «
SPChercherXContenantY ») et éviter ainsi la duplication des SP
— soit tu ne cherches pas à comprendre et tu fais directement ta SP «
SPChercherXContenantYTrieParZ », quitte à dupliquer et exploser encore
plus la quantité de SP
Idem lorsqu'on devait ajouter une colonne, lesquelles des centaines de
SP est à vérifier et/ou corriger ?
> Ha haaaa, la vieille base qu'on ne peut pas toucher - un must du
classique!
> C'est aussi là que la préparation pêche: soit le client conserve sa
base et
> il encaisse *également* les inconvénients qui vont avec, soit il y a
> migration et donc création d'une Nlle base.
On lui avait bien fait remarqué que la base n'utilisait peu ou pas les
clefs étrangères, étaient mal indexées ou conçues.
On avait même réussi à poser une clause de non-engagement sur les perfs.
Le soucis est qu'on s'est laissé mangé par l'apparente facilité des
règles métier. Au final, elles n'étaient pas très compliquées (si la
transaction va de X à Y avec une carte de la banque Z, donner tant à A1,
tant à A2, tant à A3…).
On a juste bien déchanté quand on s'est rendu compte de la complexité
des requêtes derrière, d'autant plus qu'on avait la contrainte de tout
faire en SP.
Et on a encore plus déchanté quand le client, après avoir fourni un
fichier de 2ko de règles de gestion dans l'appel d'offre, nous a fourni
le service externe réel, qui nous balançait des fichiers de 200Mo et
quelques 80.000 règles de répartition !
> Là encore, c'est une question d'analyse préalable - prendre un
> marché, c'est bien, mais pas s'il doit se transformer en sables
> mouvants dès le dev.
On n'a souvent pas assez de temps pour éponger tous les problèmes
techniques potentiels, surtout ceux à plus ou moins long terme.
Même avec des mois d'analyse, une doc de 1.000 pages reste forcément
avec des pièges…
D'autant plus que si dès qu'on avait un risque potentiel on refusait un
appel d'offre, ça fait belle lurette qu'on aurait plus de projet…
> Là encore c'est un défaut d'analyse: comment accepter des données
> externes alors qu'elles auraient dû se trouver dans la DB?
Les données provenaient de systèmes externes et/ou de sous-systèmes,
sous la forme de web-services.
> Pour te donner une idée, même les tailles & positionnements des
fenêtres de
> mon projet sont stockés dans la DB.
Pas réalisable ici.
Les données de conf sont « dynamiques » et rentrent très mal dans une
base relationnelle.
Par exemple, des règles peuvent générer entre 1 et N répartitions,
fonction de données variables de la transaction bancaire de départ (lieu
d'émission, détenteur carte, type de carte, débiteur, créditeur,
fournisseur de la carte…).
> Une fois que c'est fait, on définit une ligne de process par
> taxe/ristourne/etc puis les SP qui vont bien, puis la SP qui
> chapeaute le tout (SI il y en a vraiment besoin, par qu'il est
> facile d'automatiser ce type de traitement en chaînant les SP d'une
> façon transparente).
>
>> Le nombre de paramètres à passer aux SPs étaient effroyables
>> (jusqu'à 300 paramètres pour la plus grosse de mémoire).
>
> Ca me parait, là encore, relever d'une erreur de conception liée au §
> ci-dessus.
Non.
En gros, une transaction comporte 300 caractéristiques, comme
l'émetteur, l'origine, la destination, le type de carte, le montant…
Et en entrée on avait une conf avec quasiment autant de paramètres, qui
disait plus ou moins « si une transaction a cette gueule, elle se
décompose en X sous-transactions », chaque sous-transaction étant
elle-même représentée par des centaines de champs et pouvant être soit
un montant fixe soit un pourcentage du montant de départ.
Et le système n'était qu'un gros calculateur du type « sous-transactions
= f(transaction, conf) ».
Le gros soucis est que « f() » n'est pas linéaire… « f([a, b], c) !=
[f(a, c), f(b, c)] ». On ne peut pas faire de traitement par lots, mais
uniquement transaction par transaction.
>> Gné ? Ça devient limite de l'hérésie là… Le jour où je rajoute des
>> écrans, je dois toucher à ma BdD ? Oo
>
> Si les écrans demandent des données non primitivement renvoyées, oui
> - mais c'est la même chose où que se trouve le code: il faut bien
> modifier qq chose pour changer le résultat.
Oui, mais pas les requêtes (ie. les SP chez toi).
Ajouter un écran n'est qu'une histoire de présentation, pas de processing.
Si je veux présenter mes données en XML d'un côté et en HTML de l'autre,
mes requêtes sont strictement identiques !
> Alors il faut pousser le raisonnement à son paroxysme et utiliser
> tous les outils dispos, de l'orm à la base olap, en passant par
> (sèpulnom) les bases qui s'auto-reconfigurent par (re)design des
> flux métiers. Mais le risque du manque de connaissance est là aussi
> bien présent parce que ces outils sont tellement généraux qu'ils
> demandent des compétences très particulières (et souvent directement
> liées au métier-client) lors de leurs configurations.
Tout est une histoire de mesure.
Tombé dans l'OLAP, c'est quand même le canon de 14 pour tuer un
moustique. La mitrailleuse lourde est déjà bien suffisante et possède
assez de marge pour descendre une marmotte si le besoin s'en fait sentir.
> Je ne fais pas de java, donc je n'ai pas d'opinion sur Hibernate que
> je ne connais que de nom; mais je me rappelle qd même avoir lû pas
> mal de flammes dessus, notamment chez Pg.
Tout le monde a ses flammes contre quelqu'un =)
> Le seul bémol que j'y mettrais (mais ça n'est pas simple à faire,
> surtout quand on a la tête dans le guidon) serait d'évaluer en
> profondeur chaque outil afin de restreindre le choix aux "bons", ou
> tout du moins aux plus adaptés.
Oui, je n'ai jamais dis que je sortais un ORM et du 3-tiers dès qu'on
gueule « nouveau projet !!!! » =)
- --
Aeris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJOdRVBAAoJEK8zQvxDY4P9+fQIAIycw8Z20WLXvc3JSLY1IIrB
dE4wgkcB+S6IEAt/5fQuhfFkZqYd2X6lgiud8XwiBEO6TtCEWGcgbx6aIW9f0Uiq
o+2LDhpSOPIhTDv67/7GQlIGOhQTk3gQViKOliw93abdlF6xs7+TFTcLK81z98eX
EjcBUEixiUJX3smzSC598BLIyet9ES+7C/EE9zZSMdqIOCZQUqibSUPPG35brwhH
Av/z7TCFcaexFCoZeoNUj7pJ2evUmxHQ1k1uklgvKFMg1vjfAWe9QMXcoOP8p9NH
4Bg8Bgws9ZyXJpeB6HirDDDQeZNhMOL5CShYXI8jX4p7ZZw14Fe5ROXWHsa9tNE=
=0l2Z
-----END PGP SIGNATURE-----
Reply to: