Re: Piratage Mysql
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 18/09/2011 01:10, Jean-Yves F. Barbier a écrit :
> 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).
J'ai le droit à un joker pour les concepteurs de la base antérieure ? =)
Mais sinon, même sans ça, j'ai du mal à voir comment on aurait pu faire
mieux, une transaction bancaire étant RÉELLEMENT aussi complexe à
décrire, le modèle de données l'est tout autant.
Ou alors il aurait fallu des champs banalisés ou structurés, mais on
aurait perdu en capacité de requétage.
> Effectivement, ça n'est gérable que par du middleware.
Ben pourtant, j'ai l'impression que l'approche par SP parvient très vite
à ce niveau de complexité.
Après, il y a peut-être des manières de faire que je ne vois pas pour le
moment qui permettent de limiter les dégâts, mais de ce que je connais
des SP et de leur fonctionnement, j'en doute très fortement.
> 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?!;
Faut bien travailler parfois =)
> 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).
Les choix technologiques antérieurs n'étaient pas pertinents (Microsoft
SQL Server, SSIS…).
L'absence d'indexes s'expliquait par exemple par le fait que les tables
étaient partitionnées par date pour des contraintes de purge rapide des
données (daily rolling window). Sauf que du coup, la pose d'indexes ne
contenant pas la clef de partitionnement était interdite afin de pouvoir
aussi partitionner les indexes, sinon le rolling conduisait à une
reconstruction intégrale des indexes, qui plombait les purges (3j au
lieu de 10s).
> 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.
Tout le monde a connu un projet comme ça malheureusement…
> 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...
Ah ben c'est simple : tout le monde…
En tout cas en SSII, les appels d'offre qu'on reçoit, c'est le cas,
sinon la boîte en face l'aurait gardé en interne !
La plupart du temps, le client est elle-même prestataire et se rend
compte qu'il ne pourra pas tenir les délais de l'appel d'offre initial,
mais il doit bosser. El prend le contrat, et sous-traite au forfait une
partie plus ou moins cruciale, en tentant de cacher la misère.
Celui qui signe la sous-traitance s'engage avec obligation de résultat,
ne tiendra pas ses délais, mais la boîte d'origine pourra rejetter la
faute du retard (anticipé…) sur son presta, voire lui faire payer des
pénalités qui compenseront celles (prévues…) que la boîte doit payer à
son client final.
> J'entends bien, mais là encore les défauts de base de la DB étaient
> rédhibitoires.
Pas tant que ça.
Une fois qu'on a (enfin) pu faire comprendre au client que les SPs,
c'était pas le bon plan, on a foutu un middleware et un ORM, et roule.
En 3 semaines, le taff était fait, contre 12 mois pour la version SP (et
sans parvenir au bout…).
>> 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 :(
C'est souvent le cas en système d'info, tu ne dépends que très rarement
que de ton seul sous-système.
La plupart du temps, tu t'interfaces avec des systèmes tiers, via
web-service, échange de fichiers, FTP, SSH, messaging…
La base de données est souvent totalement contre-indiqué pour ce genre
d'usage (N clients différents, polling de masse, données peu ou pas
structurées, contrôle d'intégrité et de cohérence, chiffrement, signature…)
>> 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.
Le problème était clairement la BdD faite avec 2 pieds gauches.
Si on avait pas eu le soucis d'historique du bordel, c'est clair que
c'était OLAP, ETL, Birt, OW2…
> 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?
Toujours les mêmes problèmes :
Faut bien bosser un jour et le client cache très bien la misère.
Les 80k de règles étaient décrites dans le CdC comme ceci : « le système
doit s'interfacer un sous-système externe. En annexe, le XSD des
fichiers d'entrée ainsi qu'un fichier *d'exemple* ». L'exemple donné
était quand même assez conséquent (2 ou 3ko), XSD/XML on sait facilement
faire, on a pas forcément pensé qu'on allait se prendre ×20 au réel,
d'autant plus qu'on était plus paniqué par l'état de la BdD et de
l'obligation de SP.
Mais certes, on aurait du réagir sur le mot « exemple », et demander des
précisions sur la volumétrie.
> Et pourquoi à la base les concepteurs DB n'ont pas mis un véto absolu, au vu de
> l'état de la base à reprendre?
On a mis notre véto, et le contrat signé stipulait bien qu'on ne
s'engageait sur aucune perf étant donné qu'on était contraint sur le
modèle de données.
> 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 ;-)
Ça c'est la théorie ^_^
Dans la pratique, je sais par expérience que malgré une erreur déjà
commise, ça n'empèche pas les SSII de re-signer la même connerie plus
tard, parfois avec un peu plus de garde-fous mais resigner quand même.
L'exemple le plus récurrent étant le fait de signer un appel d'offre en
considérant le CdC client comme spécification, au motif que le CdC
paraît bien détaillé (plus de 300 pages, 1.000 besoins numérotés pris
comme « exigences », diagramme de séquence, copies d'écrans ou
mock-up…). Et qu'on se fait déboîter derrière quand on se rend compte
qu'il va falloir 2 mois de specs pour 5 jours vendus (incohérences
métiers et/ou techniques, trous dans les besoins, manques de précisions,
méprises sur des termes communs qui sont en réalité métiers)…
Le pire cas que j'ai vu passer, c'est une incompréhension sur un terme
du langage courant, qui changeait tout le fonctionnement du système si
on prenait sa signification réelle métier.
En gros, c'était comme si je te disais « tu n'as pas éteint la lumière
». En langage courant, tu en comprends qu'elle est allumée et que tu
dois aller l'éteindre. En langage métier, ça signifiait qu'elle était
peut-être allumée et qu'il fallait l'éteindre, mais aussi que si elle
était éteinte, il fallait l'allumer puis l'éteindre aussitôt !
Faute de specs dignes de ce nom, déboîtage du projet…
- --
Aeris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJOdcjDAAoJEK8zQvxDY4P9Z6kH/3YFFUrlZMqsltKCoW9EwN5h
vM+CGeEtAD1wFDuzPMODJdej6TiMTRHEesZY2PSXBn+vdlPqwXfb0y/HqOd7PfCC
pQcpqR+DNqh/xCsBkVO7Oa8aDUhxfap1rTwrFcTKvBUulKNaaKwY3Vt8T/1sYQkt
kEEZBP847AURx6++7InvO0D6u4JkdkrIX7bnc9aAG6U7LBVtMTpP/49+hzRMXStm
sl/IvkNXQ/lIouIZou+2KnR0eVf9eGAER44Sd+FyfidneotzB54G9PFuoNwdMZ3h
ie9g/UiXgJeW33DEpQaNQgdLdI1z4VJWAjBehR56OnwuL7I72P8iCHAQs7qihOg=
=L5Rl
-----END PGP SIGNATURE-----
Reply to: