Juste en passant, le SQL PASS se déroule cette semaine à Seattle et le keynote (la grosse présentation d’ouverture) a eu lieu hier.
Principale annonce : Denali devient SQL Server 2012, et sortira donc en 2012 😉
Deux très bons résumés à lire sur le sujet: le compte rendu de Jean-Pierre Riehl (avec qui je co-animerai la session modélisation dimensionnelle aux Journées SQL Server) et celui de Brent Ozar, qu’on ne présente plus.
Bonne lecture!
Juste un petit mot pour vous dire que j’animerai surement une session au SQL Rally Journées SQL Server, un événement organisé par le GUSS (section francophone du PASS), les 12 et 13 décembre 2011 sur le campus de Microsoft à Issy les Moulineaux.
Le thème de la session sera la modélisation dimensionnelle (Kimball, Inmon et autres).
Je vous en dirai plus quand j’en saurai plus 🙂
PS: Finalement le nom de l’événement ne sera pas SQL Rally mais Journées SQL Server!
Via le mailing de Brent Ozar & Co – je recommande vivement cette newsletter à quiconque bosse de près ou de loin sur SQL Server – un petit outil sympa qui reformate vos requêtes T-SQL directement dans votre navigateur web : Poor SQL. Ça marche plutôt bien, le voilà d’ailleurs déjà qui atterrit dans ma barre de favoris!
Et pour ceux que ça intéresse, j’en profite pour vous rappeler l’existence du Blitz de Brent Ozar, script SQL qui permet de prendre en main en 60 minutes les serveurs SQL dont vous venez d’hériter.
Je le disais tantôt, j’ai craqué pour le tout nouveau Macbook Air d’Apple.
Pour un consultant décisionnel spécialisé dans les technologies Microsoft, c’est vrai que c’est un peu ironique de passer à un produit du concurrent numéro 1. Je le justifie comme une preuve d’ouverture d’esprit… Je vous promets que de temps en temps ça passe 😉
Et puis je ne suis pas le seul. Je me suis renseigné, et la plupart des gens qui m’inspirent le sont. Ok c’est un peu un raisonnement de mouton, mais même dans mon écosystème vraiment pro-Microsoft les meilleurs sont sur Macbook.
Alors pourquoi un Mac ? Pour le hardware, évidemment, c’est super bien fini, bien pensé, le matos est sexy, la résolution d’écran est la bonne, à l’heure actuelle c’est juste le top en terme de design et de finition. Mais c’est également pour le software : OS X Lion est un bijou. Tout est intuitif, tout est facile. C’est surement la version de l’OS la plus facile à prendre en main pour quelqu’un qui vient du monde Windows.
Pourquoi ce Mac ? Le Macbook Air c’est le partenaire idéal du consultant (non développeur). Il est fin, léger (1.3kg), format A4, il démarre en 10 secondes et il a une grosse autonomie. C’est la classe en salle de réunion, c’est la classe pour faire un pitch à un client, c’est la classe pour faire une présentation à 40 personnes, c’est toujours la classe ! Je dis consultant mais pas développeur parce même avec un écran externe grand format, il manque de RAM pour en faire une machine de dév à temps plein – j’en reparle plus bas.
Pour ceux qui envisagent de « switcher », voici les points qui m’ont le plus impactés dans mes premiers jours, dans le désordre :
Enfin, par rapport à mon activité de consultant, j’ai installé une machine virtuelle Windows. Une machine virtuelle c’est avoir un Windows complet dans une fenêtre dans OS X. Et malheureusement c’est là où n’avoir que 4Go de RAM pêche un peu. En effet cela veut dire qu’on va partager la RAM entre Mac OS X et Windows. Deux Go de RAM pour Windows Server 2008R2 avec SQL Server et toute la stack BI Microsoft, ça fait pas beaucoup.
Mais si on fait attention aux services qui se lancent, on se retrouve avec Office 2010 pour Windows (à moi les connexions OLAP et SQL Server, à moi PowerPivot et les nouveaux tableaux croisés dynamiques avec slicer), et carrément un SQL Server 2008R2 complet qui tourne au poil. Pour un POC, une démo ou une présentation ça marche nickel. En plus SQL Server profite vraiment bien du SSD: c’est ultra rapide… jusqu’à ce que ça crash à cause de la RAM ;). Et puis c’est tellement sexy d’avoir Visual Studio et Management Studio sur mon petit Macbook!
Vous l’avez bien compris je suis conquis par cette machine! Je vais attendre quelques mois et je vous ferai un autre compte rendu, une fois passée la période d’euphorie initiale, et on verra si la passion tient dans la durée 🙂
Ceci est un article technique (bases de données SQL), n’hésitez pas à l’ignorer si ça ne vous intéresse pas 🙂
Depuis quelques jours nous galérons avec mon équipe à identifier une anomalie de traitement plutôt pénible dans l’ETL qui charge tous les soirs le chiffre d’affaire.
Nous avons enfin identifié l’erreur: le compte de service qui exécute le chargement le soir est configuré en américain sur la production, alors qu’il est en français sur les plateformes de développement. C’est dommage lorsqu’une date de bascule au 1er mai est interprété comme le 5 janvier en production. En effet le 05/01/2011 devient 01/05/2011 avec un format de notation américain.
Sachant que changer le paramétrage d’un compte de service en production peut prendre 3 ans de conflits politiques entre les différentes équipes (pour 2 minutes d’implémentation), nous avons décidé de faire évoluer les requêtes SQL pour qu’elles n’utilisent plus aucune conversion implicite. L’objectif c’est de rendre le code insensible aux paramètres de langue.
En gros en SQL ça veut dire que ça c’est interdit: CAST(‘2011-05-01’ AS DATETIME), de même que référencer directement une date en chaîne de caractère : WHERE MonDateTime = ’05/01/2011′
A la place on doit faire ça : CONVERT(DATETIME,’01/05/2011′,103), ou ça : CONVERT(DATETIME,’2011-05-01′,102). En utilisant CONVERT, on peut préciser le format de la date de manière explicite: 103 pour JJ/MM/AAAA et 102 pour AAAA-MM-DD.
Ne laisser aucune conversion implicite (date ou autre) est définitivement une bonne pratique qu’il ne faut pas oublier. Pour les dates, c’est aussi une info qu’il faut savoir transmettre aux utilisateurs et MOA qui requètent les bases en SQL.
Pour plus de détail:
Pour faire suite à l’article d’avant-hier, celui sur la déformation de notre vision du monde que cause les outils que l’on emploie, je voulais vous parler de la recherche textuelle sur la plateforme SQL Server. Désolé si certains sont déçus mais oui c’est un point technique 🙂
Alors pourquoi faire le lien entre cette problématique et la recherche textuelle ?
Dans une base de données on a une obsession : tout mettre dans des tables composées de lignes et des colonnes. Naturellement dans ce modèle l’unité de traitement minimale est la cellule, l’intersection d’une ligne et d’une colonne.
Très bien, mais que faire quand la cellule contient une entité unique, comme demandée par la modélisation, mais que cette entité se décompose de manière complexe ? Je pense par exemple à un descriptif produit ou un commentaire client. Comment exploiter une information humaine, un avis, une description, comprise dans une chaîne de caractère, avec des outils qui ne savent pas vraiment travailler à ce niveau de granularité ?
Et bien on fait comme on peut, mais en général ce n’est pas très joli !
Pour parler d’une situation précise, je monte actuellement une solution décisionnelle qui stocke et analyse pratiquement toutes les informations concernant le parc informatique d’un grand groupe. On pourrait penser que sur ce domaine fonctionnel on n’aurait pas de surprises dans les données: que du technique ou du numérique. Et bien détrompez-vous, remonter l’ensemble des applications installées sur les postes, sur un parc de 30’000 machines, dans 10 langues (vive l’Unicode), ça donne 3 millions de lignes à brasser par jour…
Pour vous donner un exemple : j’ai environ 1500 valeurs distinctes par jour d’applications qui contiennent le mot ‘Microsoft’, dont 500 qui contiennent le mot ‘Office’… Là dedans je dois retrouver les différentes éditions d’Office 2003 et 2007 pour faire le suivi du licensing.
Miam !
Le minimum qu’on puisse dire c’est que j’ai un problème de qualité de données. L’approche que je préfère sur ce genre de problème c’est d’utiliser les outils décisionnels pour instaurer un cycle d’amélioration des données (Tip 131):
Bien ! Le problème c’est que pour faire l’étape 2 il faut pouvoir interagir sur la donnée : est-ce que mon descriptif d’application contient ‘Office’ ? Enfin, est ce qu’il contient ‘%Office’, ‘Office%’, ‘% Office %’, ‘%Office%’… La différence ?
Presque facile pour Microsoft Office, mais pas pour Adobe et toutes les variations de flash, ni pour IBM, ni Mozilla, ni pour toutes les autres en fait…Et ‘0ffice’ ? ‘Offisse’ ? On peut les oublier pour des champs fournis par les éditeurs eux-même, mais pour une recherche dans des champs saisis à la main ?
Pour pouvoir traiter tous ces cas de figure on va utiliser des critères de recherche compliqués, conditionnels, qui impliquent des traitements unitaires multiples sur chacune des cellules les unes après les autres: les performances s’écroulent. En temps de réponse on passe de moins d’une seconde sur une table bien indexée à plusieurs minutes sur une recherche en ‘%…’. En fait c’est une particularité dans la manière qu’ont les bases de données relationnelles de stocker et traiter l’information qui force une lecture complète de la table à chaque fois.
On retrouve cette limite là dans tous nos outils :
Ça plus le fait qu’il faille créer toutes les règles de gestion une par une de manière exhaustive. Vivement que les IA viennent nous filer un coup de main !
Malheureusement pour le moment il n’existe pas de solution magique, une recherche textuelle étendue sur une base de données relationnelles classique aura forcément un coût important en performance et/ou un résultat foireux. La prochaine fois que vous verrez un site web équipé d’un moteur de recherche bancal, ne cherchez pas pourquoi… Et c’est là que le bas blesse: à force de galérer avec ce type d’opérations on ne les propose plus, on ne les implémente plus, et on en vient à penser qu’elles ne sont pas possibles.
Pourtant Google y arrive, et sur des volumes de données autrement plus important! C’est d’ailleurs pour ça que pour l’avenir j’ai espoir dans la prochaine génération de bases avec moteur de stockage en colonne / vertical. Va bien y avoir un génie quelque part qui va nous révolutionner les recherches textuelles là-dessus!
La BI ça vous gagne! 