The SQL Grrrl

Extirper la sainte vérité, combattre les vilaines requêtes du monde RBAR des developpeurs qui ne pensent pas par lot ou set (et match). Atteindre la pureté et le nirvana des bonnes clés, de l'index puissant, de l'instruction concise avec le SARG précis.

Vâlâ... c'est beau, c'est bien, ça carbure gentiment...

Et puis à côté de cela il y a le monde de la BI.

Parce qu'on accumule ces données.

Des tas

Des paquets

Des montagnes

Des mines d'or

Et qu'on aimerait bien les croiser. Trouver des causes ultimes, prédire enfin. La connaisssance c’est le savoir, la puissance ultime…

Tadaam , clairon, trompettes kpi et dashboard…graphiques lumineux, indicateurs incandescent, rapports sexys..

Oui sauf que moi… moi j’adore aller au charbon. Extraire ces données coriaces de leur gangue de boue.

Une donnée de prod c’est moche et sale , souvent , comme un diamant brut.

·         Paske un jour a on a décidé que pour faire une fleur commerciale on allait changer mr en « madame » sur le contrat d’assurance vie. Oui ca diminue la prime *

·         Paske les contraintes d’intégrités c’est bien suffisant de les mettre dans le code la db c’est qu’un entrepot idiot.

·         Paske, merveille renouvelée de la nature , l’utilisateur saura toujouuuuurs tordre vos applications pour faire rentrer des ronds dans des carrés. Ou pas J

Alors les données de prod quand on va les chercher on prévoit des « dirty data corner » parce qu’il faudra bien expliquer que tout compte fait dans notre cube le calcul de la progression des parts de marché est un chouilla moins heu… arrogante ?

Sur des millions et des millions de lignes les erreurs sortent…on les remonte, on les explique, on les traite si possible.

Et on polit tout cela gentiment.

Et on arrive peu à peu au Saint Graal… le ONE VERSION OF THE TRUTH….

Un genre de « on disait que » mais au moins fixé une fois pour toute. Placer au possible dans un lieu centralisé serein et sécurisé les dix commandements.. heu les formules de calcul de rentabilité …

Pour etre honnête et franche c’est la partie la plus compliquée…j’ai vu des projets s’arreter car personne ne pouvait finalement prouver la validité ou pas d’une donnée. Argh sic.

L’analyste aime solitairement sauver un rapport adhoc en excel et lui apliquer gentiment un x² pour redresser ses ventes…

Je vous reparlerai de self BI plus tard.

Là juste que mon univers n’est pas si divisé…dans le monde décisionnel c’est encore plus de données, plus de traitement , plus de défis… et du cambouis pleins les mains.

LIKE IT !!!!

*mmh j’ai toujoours un petit fremissement de joie à vous rappeler que mon espérance de vie est statistiquement supérieure à la vôtre…..

D'aucun trouvent SQL lent.

Amusant....

Imaginons qu'on les soumette à la meme torture que celle dénotée par ma commande chérie 'set statistics IO ON'* pour extirper la verité d'une stored proc nonchalante.

(15 row(s) affected)

et voila ce que CA fait

je vous envoie le mantra et les incantations pour extirper ces 15 pauvres rows...pire que l'extraction des comédons d'un ravagé par les hormones... rendez-vous en bas de page....

Table 'Types'. Scan count 56, logical reads 8648, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads

Table 'LC_FunctionState'. Scan count 15, logical reads 8074, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Table 'Worktable'. Scan count 507557, logical reads 4417612, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Table 'Functions'. Scan count 10, logical reads 2068, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Table 'LC_EqFuncLocRelation'. Scan count 32, logical reads 29260, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Table 'Locations'. Scan count 5, logical reads 1264, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Table 'Equipments'. Scan count 30, logical reads 204620, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Table 'LC_EquipmentState'. Scan count 27, logical reads 23638, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Table 'LC_SubEquipment'. Scan count 27, logical reads 13785, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Table 'CommonConstructionTypeProperties'. Scan count 5, logical reads 598, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Table 'ConstructionClassData'. Scan count 1, logical reads 3, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Table '#55EAA1D1'. Scan count 4, logical reads 40, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Table '#08C03A61'. Scan count 4, logical reads 6688, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Table 'Event'. Scan count 9, logical reads 295, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Table '#56DEC60A'. Scan count 0, logical reads 220, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Table '#04EFA97D'. Scan count 0, logical reads 30, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Table '#59BB32B5'. Scan count 0, logical reads 2, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Table '#5D8BC399'. Scan count 2, logical reads 9, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Table '#5C979F60'. Scan count 4, logical reads 1671, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Admirez les lectures et les acces a la worktable générés par les subqueries...

Imaginez que pour préparer du riz vous ouvriez le sachet , preniez un grain , le placiez dans la casserole et réiteriez l'opération ...

C'est pas rapide hein!!!

Pauvres de nous!!!! Là j'ai renvoyé le dev sur sa copie , j'attends...de pied ferme.

*'set statistics IO ON' ne ment pas . Jamais. elle est bien plus utile que le temps écoulé car quelle que soit la machine vous lirez toujours le même nombre de pages à données et objets égaux. Elle permet très rapidement de voir où le bât blesse et de sentir d'où vient le vent.

On continue dans le billet d'humeur...

Le génial F'murr  a fait assez bien avancer la cause du mouton...

N'empêche, je soupire souvent devant les instincts grégaires de mes congénères humains....

La plupart d'entre nous se retrouvent dans l'I.T. suite à une harmonieuse conjugaison d'un certain sens logique, d'un soupçon de curiosité intellectuelle, d'une bonne dose d'inadéquation aux rapports sociaux de base--quoique la geekitude devienne de plus en plus hype-- et surtout d'une montagne de paresse qui, des radiateurs académiques les envoie tout droits sur les grands plateaux de développeurs.....

Sainte paresse, elle nous amènera toujours à préférer coder une semaine que passer deux jours à une opération manuelle...

Même paresse qui nous pousse a recycler le code du voisin..J’avoue, je suis partagée quand je vois se répéter a l'infini les mêmes tics de programmation comme des mantras fractaux...

allez hop juste un exemple...

le fameux

"WITH NO LOCK"

Un jour, un gars a trouvé ce truc génial que ca marche vachement plus viiiiiite.

Mouais super...

Apres tout la concurrence d'accès c'est le deal, la consistance on s'en tape un peu.. N’est-on pas dans une économie de marché, de libre échange ???

Yep

Et c'est la que les petits moutons arrivent...

On copie/colle, on récupère, on se le chuchote, on se le poste, c'est comme la gangrène....

Et encore je ne mets mes blanches mains que dans le TSQL...

Je n'ose imaginer les fioritures absconses, les mauvais trip, les routines bâclées et autres qui fleurissent a l'infini et se propagent tels des virus  dans les langages compilés.

Tout cela me rappelle furieusement l'histoire des saucisses:

Un homme demande a sa femme pourquoi elle coupe toujours les extrémités des saucisses avant de les cuire.

Elle lui répond qu'elle a toujours vu sa mère faire ainsi.

Ils posent donc à l'occasion la question à la mère

Elle répond que sa propre mère le faisait aussi ainsi.

Le dimanche a la maison de retraite, ils interrogent l'ancêtre qui leur répond benoitement

"Ben c'est parce que ma poêle était trop petite et j'avions point d'argent pour une autre"

Combien de saucisses coupées dans vos codes ???

Et ne venez pas me chanter que vos commentaires, système de sourcing et autres évitent ces mésaventures....

Moutons vous dis-je...

Croisez vos infos, testez-les .. et oserais-je ?

Comprenez-les!

Soyons franche!

Mes nombreux sacs a mains ---que j'assortis compulsivement à mes toutes aussi nombreuses paires de chaussures-- sont des zones de non-droit.

Tout s'y entasse joyeusement dans un inventaire digne de Prévert et je fantasme parfois d'en sortir un immense lampadaire comme Mary Poppins... ce qui ferait son petit effet en reunion. (oui j'adore faire effet en reunion--je développerai plus tard)

Hors de question que je vous en dévoile le contenu...il y a un NDA ancestral entre femmes à ce propos. Si je romps cette Omerta, je risque gros.

Mon iphone lui n'ayant pas ces scrupules je vous joins une photo volée .. un jour dit de "decluttering" (genre de defragmentation rituelle de la chose)

Pourtant de la mignonne pochette a la plus grande besace tous sont conçus avec un minimum de logique et d'intelligence: poches interne, mousqueton pour les cles, compartiment pour gsm etc...

Rien a faire, je plonge la main et farfouille chaque fois longuement --avec essai erreur-- pour en extraire, clé/argent/makeup/fouet et menottes...

C'est LENT, c'est LONG

Parfois je finis par tout renverser pour récuperer plus vite le ticket du parking...

Et le pire ... le pire c'est que je retrouve souvent cette sensation dans les applications que j'audite!!!!

Chers développeurs...

Très chers développeurs,

--à qui je consacre mon âme, mes forces ma fougue ma jeunesse et les neurones pas encore brulés de ma tête blonde...

NON SQL N'EST PAS UN GRAND SAC FOURRE TOUT

Une base de donnée n'est pas une nebuleuse amorphe dans laquelle on prend un maximum de choses pour les retrier ensuite dans son petit langage chéri...

CE N'EST NI ELEGANT NI PERFORMANT NI MEME INTELLIGENT.

Avouons le c'est carrément stupide.

Oui je vous vois hocher de la tête en vous disant mepourkikellmeprendohlablondelà

Pourtant...

A chaque fois que vous utilisez un select * par flemme

A chaque fois que vous chargez toute l'entité, photo comprise, au chargement de votre appli pour avoir votre dop down liste

A chaque fois que vous négligez la puissance de recherche des algorithmes du moteur SQL

A chaque fois que-comme me l'affirmait avec arrogance encore hier un architecte-- vous placez votre intégrité référentielle dans VOTRE code-- c'est bien suffisant

A chaque fois que vous réinventez l'eau chaude et les roues

A chaque fois que vous négligez votre modélisation, que vous prenez des mauvais types, que vous comparez des dates en strings , que vous parsez de l'xml a tout crin sans meme le typer

Que vous usez des clés sans en indexer les colonnes , que vous ne vous souciez pas meme de poser d'autres indexs..ni meme de songer une seconde a l'ordre "naturel" de vos donnée pour choisir le cluster adequat

A chaque fois que seul le result set vous importe et que la lenteur devient une affaire de hardware

A chaque fois alors vous êtes pareil a une blonde émechée qui cherche en vain ses clés au fond d'un immense sac en jachère en vacillant sur ses hauts talons pendant que le client s'impatiente!!!!

demain je vous parlerai des petits moutons...de la peste et du cholera :)