On Sat, 17 Sep 2011 23:46:49 +0200, Aéris <ae...@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. -- 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/20110918010239.002b8430@anubis.defcon1
