Céline Fion est plus rendu américaine et Garou… sibole, s’endormir au volant d’une Ferrari il faut le faire quand même :o (d’ailleurs, ça fait même des années que j’en entends pas parlé de lui :o )
Comme représentant, on a mieux :o (François Pérusse, Anthony Kavanagh, Stéphane Rousseau, …)
Il y a ça mais l’autre problème c’est que vu que je suis en arrêt de travail, j’aurais pas de paye avant au moins 2 semaines à partir de la semaine prochaine et mon compte est assez bas (malgré que je pourrais me faire 300$ presque maintenant en ouvrant un compte dans une autre banque que celle que j’ai présentement)
Pardon? :nexath Ben pitin, j’vois pas où est le mieux! :MDR Sauf que là, par rapport aux deux autres beugleurs, c’est censé être du comique volontaire.
TTB : j’ai validé l’optimisation que j’ai faite aujourd’hui… à confirmer quand même par les fonctionnels. Mais j’ai pas trop de doute… j’ai donc modifié 3 lignes dans une requête SQL pour passer de presque 12h à… 3… secondes :sol:
Ouaip mais c’est ça qu’il faut que j’attend 2 semaines. Déjà qu’il faut que j’aille tous les papiers du médecin (chose que j’attend encore après), après il faut que je fasse ma demande sauf que moi c’est 80% du salaire si ma mémoire est bonne
Même pas, je pense que c’est SQL Server qui a pris des chemins “un peu” détournés pour faire un truc qui semblait pourtant pas si dégueu. Mais bon, la logique du mec qui a codé ce truc est tout de même… discutable :paf:
C’est le problème des dévs qui développent des trucs et se contentent du fonctionnel. Ca fait ce qu’on veut alors c’est bien… que ce soit codé avec les pieds et que ça prenne des plombes ça les dérange pas pour la plupart :neutre:
Une autre aussi, j’suis passé de plus de 40s (et donc un timeout dans l’appli) à… 0s… juste en utilisant les bons data types et éviter de se taper une conversion implicite inutile… encore une erreur stupide :neutre:
De toute façon, je déteste nos dévs… ce sont vraiment trop des burnes :o Pourtant je leur ai dit que 6 mois d’expérience chez M6 c’était pas bon signe [:mpay]
[quote="juju251"]
:ouch: De 12H à ... 3 secondes !?! :nexath
Ca c’est de l’optimisation. :super: :paf:
[/quote]
Le truc dingue c’est que ça génait personne quoi… 12h… pour pondre à peine 20 000 lignes :pt1cable: Ca aurait été plus vite de sous traiter la requête par 3 indiens en offshore :ane:
Edité le 05/11/2016 à 08:28
Je fais pas mal de SQL et je mouline parfois des trucs bien gros, mais 12 heures de traitement pour pondre 20000 lignes j’ai jamais vu ca :nexath j’ai fait des scripts pour mouliner des fichiers de plusieurs centaines de milliers de lignes et me les rendre “exploitables” (en gros passer d’un état imprimable à un CSV à injecter dans une base) ca prend 10 fois moins de temps et c’est qu’un pauvre script :nexath
Oui, c’est pour ça que je pense qu’avec un truc pourtant pas si fou, SQL Server est parti dans un truc complètement foireux. Le dév n’est pas seul coupable dans l’affaire même si on pouvait clairement simplifié :neutre:
C’était un truc du genre :
WHERE daterelease < (si la date existe dans l’enregistrement suivant, alors la date de l’enregistrement suivant, sinon 31/12/9999)
Ca devait pourtant pas être si coûteux vu que la sous-requête utilise un requête de la clause WITH qui est instantanée… Bref, une jointure externe ça a réglé le problème tout en rendant le truc plus lisible Et le plan d’exécution était clean… ça pue le truc qui fait un nombre de requête égale au nombre de lignes à lire puissance ce même nombre :pt1cable:
un CASE avec une requête dans la condition, c’est le mal :ane:
Edité le 05/11/2016 à 08:45
Effectivement, si les mecs utilisent des générateurs de requêtes SQL, quand je vois la gueule de la requête pour palucher 4 malheureuses tables alors que tu pourrais la faire en moins de 100 caractères, ca sent pas l’optimisation :nexath
Mais j’ai la vieille habitude de faire du SQL à la main, y a des choses qui se perdent :arf:
Le métier ce perd. Pour beaucoup de recruteur un développeur sait tout faire… mais bon, quand tu demandes à un dév .Net de faire du SQL ben t’arrive à ce genre de connerie :neutre: Le SQL c’est pas inné, il y a une “stratégie” à connaitre… ça m’intéresse beaucoup plus que le développement appli justement pour ça
Ils ont du bol d’avoir un DBA qui a fait du dév en attendant, parce que j’en ai connu, ils étaient uniquement orientés système (très très fort dans le tuning du reste) et ne pannaient que dalle au SQL :neutre:
Edité le 05/11/2016 à 08:51
Ca me rappelle un peu ma macro sous Excel pour traiter 2 pauvres milliers de lignes (enfin à peu près, je ne me souviens plus du nombre exact) : En gros, fallait 3h 30. :nexath
Euh, t’endez, stop !
On arrête tout là. :paf:
Je regarde le machin, je fais autrement : 40 secondes. :miam: :ane:
Et je suis sur qu’on peut faire encore mieux, mais vu que c’était pour un traitement unique ça m’allait bien. :paf:
Comme pas mal de trucs.
Genre le dév sur automate / micro-contrôleurs, en réordonant certaines séquences on arrive a gagner pas mal en temps de cycle. :neutre:
Après, c’est sûr, faut accepter de se palucher la doc et accepter de passer du temps a tester les séquences critiques pour gagner du temps au final. :ane: