Retours d'expérience, réflexions et défis techniques sur SQL Server, le développement et l'architecture. Écrits par des ingénieurs qui codent au quotidien.
Le Cardinality Estimator est sans doute le composant le plus mal compris de SQL Server. Pourtant, c'est lui qui décide si votre requête met 200 millisecondes ou 20 minutes. On décortique son fonctionnement — et pourquoi les mises à jour de 2014 et 2017 ont tout changé.
Scrum n'est pas une religion. Kanban n'est pas un remède. Waterfall n'est pas mort. Comparons les méthodes de gestion de projet pour de vrai, avec leurs vrais défauts et leurs vrais atouts.
Tout le monde sait créer un index. Mais choisir le bon type, le bon ordre de colonnes, savoir quand un index filtré suffit, quand un columnstore est plus adapté — c'est une autre histoire.
Il estime combien de lignes votre requête va retourner. Et sur cette estimation, tout l'optimiseur construit son plan. Mauvaise estimation = mauvais plan = catastrophe. Explorons pourquoi.
Le dev veut livrer vite. Le DBA veut protéger. Le dev voit un index comme un accélérateur. Le DBA le voit comme un coût de maintenance. Et si les deux avaient raison — et tort en même temps ?
Plus d'écrans tactiles ? Vraiment ? Et si 2035 sonnait le glas de l'app store tel qu'on le connaît ? Projection informée — pas science-fiction — sur ce qui se prépare déjà dans les labos.
Un modèle génère du contenu. Un autre le détecte. Le premier s'améliore pour tromper le second. Le second s'améliore pour le rattraper. C'est une course armée — et personne ne gagne.
"Sécuriser, ça ralentit." "La haute dispo, ça complexifie." Vraiment ? On démontre que les deux sont les deux faces d'une même pièce — et que les négliger l'une pour l'autre mène à la catastrophe.
Tout le monde veut des microservices. Personne ne veut gérer le distributed tracing, les partial failures, et le debugging en production un vendredi soir. Parlons franchement du monolithe modulaire.
Le build est vert. Les tests passent. La prod brûle. Pourquoi ? Parce qu'un pipeline vert ne prouve qu'une chose : que vos tests ne testent pas ce qui casse en production.
"On documentera plus tard." Plus tard n'arrive jamais. Et quand le mec qui a écrit le code part, tout le monde maudit son absence de doc. Voici comment écrire des docs que les gens veulent lire.
Nous écrivons à partir de vraies missions, de vrais bugs, de vraies nuits blanches. Si un article vous a aidé, contrarié, ou donné envie de débattre — écrivez-nous. Les meilleurs sujets viennent de vous.
Lancer la discussion