Re: Piratage Mysql
On Sat, 17 Sep 2011 23:46:49 +0200, Aéris <aeris@imirhil.fr> wrote:
...
> > 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…
Je suis bien d'accord.
...
> 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…).
Je vois, il va falloir commencer à plancher dur sur des ptit qq choses
polymorphiques à encryptions multiples targetant aussi bien ces DBs que leurs
backups...
...
> 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…
Ok, je vois mieux le tableau.
...
> > 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.
Je rajoute "de base" à mauvaise analyse: quand on se retrouve avec des tables
et des filtres aussi gros c'est que la conception de base s'est fourrée le
doigt dans l'œil jusqu'au trognon. (je parle de l'antérieur).
> > 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 ?
Effectivement, ça n'est gérable que par du middleware.
> > 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.
Là n'était pas le PB, il se trouve dans la phrase au-dessus: comment
avez-vous pu accepter de reprendre cette DB telle quelle?!; je ne parle
même plus des tables à 400 colonnes, mais bien des mauvaises indexations; c'est
typiquement symptomatique d'un mille-feuille jamais retouché (à moins que les
concepteurs de base n'aient *vraiment* été des burnes, ce qui existe
malheureusement).
> 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 !
Wai, ça revient à l'histoire de mon pote: on vous a refilé le truc dont
personne ne voulait en cachant bien la merde au chat.
D'ailleurs, je me demande si ça ne serait pas une idée de site pro à monter
ça: un répertoire des boîtes qui se foutent du monde rapport à leurs demandes
impossibles...
...
> 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…
J'entends bien, mais là encore les défauts de base de la DB étaient
rédhibitoires.
> > 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.
C'est plus une usine à gaz mais un complexe pétrolier au grand complet ton
histoire :(
...
> 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.
Je vois.
...
> > 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.
Ben pas vraiment, vu comment tu décris la chose (d'un autre monde:)
OLAP, middleware(s) et le reste qui va bien avec - mais même comme ça, ça
reste du monstrueux construit sur une base inacceptable (la DB).
Ca permet aussi n'importe quelle gymnastique dans le cadre du reporting sans
trop d'efforts à fournir.
Les trucs que je ne comprends pas c'est pourquoi vous avez pris l'affaire
sachant que la base était pourrie (principe de la chaîne), ni cassé le
contrat lorsque le client vous a avoué que c'était en fait 80k règles qu'il
fallait appliquer?
Et pourquoi à la base les concepteurs DB n'ont pas mis un véto absolu, au vu de
l'état de la base à reprendre?
Mais remarquons le bon côté de la chose: en se faisant bien mettre une fois
comme celle-là on reste normalement vacciné un long moment après ;-)
--
The attacker must vanquish; the defender need only survive.
Reply to: