-----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----- -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4e75c8cf$0$28053$426a7...@news.free.fr
