Imaginez la scène. On est le 2 juillet, votre directeur financier attend le rapport des ventes du deuxième trimestre. Vous lancez votre script, fier de votre rapidité, et vous lui envoyez un chiffre global de 1,2 million d'euros. Le lendemain, le comptable appelle, furieux. Ses calculs pointent vers 1,25 million. Ces 50 000 euros de différence ne sont pas une erreur de saisie, c'est le résultat direct d'une SQL Query For In Between Dates mal conçue qui a tout simplement ignoré les transactions effectuées le dernier jour du mois à partir de 00:00:01. J'ai vu cette erreur coûter des carrières parce qu'elle brise la confiance entre l'équipe technique et la direction. On pense que les dates sont simples, mais en base de données, elles sont un champ de mines.
Le piège mortel de l'opérateur BETWEEN
L'erreur la plus fréquente que je croise chez les développeurs, même ceux qui ont cinq ans d'expérience, c'est l'utilisation aveugle de l'opérateur BETWEEN. Sur le papier, ça semble naturel. On écrit "WHERE date BETWEEN '2024-01-01' AND '2024-01-31'". On se dit que SQL est intelligent et qu'il comprend nos intentions. C'est faux.
Le problème majeur réside dans la nature inclusive de BETWEEN et la précision des types de données comme DATETIME ou TIMESTAMP. Si votre colonne contient des heures, et c'est presque toujours le cas dans un système de production, votre requête va inclure tout ce qui s'est passé le 1er janvier à minuit pile, mais elle va s'arrêter exactement au 31 janvier à minuit pile. Toutes les ventes réalisées à 14h30 le 31 janvier ? Disparues de votre rapport. Vous venez de perdre une journée entière de données sans même recevoir un message d'erreur.
La solution des limites asymétriques
Pour éviter ce carnage, vous devez arrêter d'utiliser BETWEEN pour les dates. La méthode la plus fiable consiste à utiliser une combinaison de "supérieur ou égal" et "strictement inférieur". Au lieu de viser la fin du mois, visez le début du mois suivant. En écrivant "WHERE date >= '2024-01-01' AND date < '2024-02-01'", vous garantissez que chaque microseconde du mois de janvier est capturée, sans exception. C'est une habitude qui semble insignifiante, mais qui sépare les amateurs des professionnels qui dorment sur leurs deux oreilles pendant les audits.
SQL Query For In Between Dates et le cauchemar des fuseaux horaires
Si vous travaillez sur une application qui dépasse les frontières de la France, vous allez au-devant d'un désastre si vous ne gérez pas les décalages horaires dès la requête. J'ai travaillé pour une plateforme e-commerce où les rapports étaient générés en heure de Paris alors que les serveurs étaient configurés en UTC. Résultat ? Les commandes passées par les clients californiens le dimanche soir apparaissaient le lundi matin dans les bases, faussant totalement les statistiques de performance du week-end.
L'erreur classique est de filtrer sur une colonne de date sans convertir explicitement le fuseau horaire de référence. Si votre base de données stocke en UTC, ce qui est la norme industrielle recommandée par la plupart des architectes système, chercher des données entre deux dates locales sans conversion revient à tirer à l'aveugle.
L'illusion du serveur local
Beaucoup de gens pensent que parce que leur entreprise est basée à Lyon, le serveur "sait" qu'il doit parler français. Sauf que votre instance cloud est peut-être en Irlande ou en Virginie. La solution n'est pas de changer l'heure du serveur, ce qui briserait d'autres processus, mais d'utiliser des fonctions de conversion comme AT TIME ZONE à l'intérieur de votre SQL Query For In Between Dates. Vous devez normaliser votre entrée utilisateur vers l'UTC avant que la base de données ne commence son scan d'index. Si vous ne le faites pas, vos comparaisons de dates ne seront jamais constantes d'un serveur à l'autre.
L'impact dévastateur des fonctions sur les colonnes indexées
Voici une erreur de performance qui peut mettre votre base de données à genoux dès que vous atteignez quelques millions de lignes. Supposons que vous vouliez les ventes de l'année 2023. Un développeur pressé écrira souvent "WHERE YEAR(date_commande) = 2023". C'est élégant, c'est court, et c'est une catastrophe absolue pour la performance.
En appliquant une fonction sur la colonne dans la clause WHERE, vous empêchez le moteur de base de données d'utiliser l'index que vous avez si soigneusement créé sur cette colonne. Le moteur est obligé de lire chaque ligne de la table, d'appliquer la fonction YEAR() sur la valeur, puis de vérifier si elle correspond à 2023. C'est ce qu'on appelle un "Full Table Scan". Sur une table de 50 millions de lignes, une requête qui devrait prendre 10 millisecondes va soudainement prendre 30 secondes et saturer votre processeur.
Avant et après : optimisation réelle
Regardons la différence concrète dans un scénario de production. Imaginez une table "transactions" avec un index sur "created_at".
Approche erronée :
Le développeur utilise WHERE DATE(created_at) = '2024-05-01'. Le moteur de base de données ignore l'index. Il parcourt les 10 gigaoctets de données de la table. La production ralentit, les utilisateurs voient des temps de chargement interminables, et le DBA reçoit une alerte critique en pleine nuit.
Approche professionnelle :
Le développeur utilise WHERE created_at >= '2024-05-01 00:00:00' AND created_at < '2024-05-02 00:00:00'. Ici, le moteur voit une valeur brute comparée à une colonne indexée. Il effectue un "Index Seek", trouve instantanément les lignes concernées en quelques microsecondes et libère les ressources pour d'autres tâches. La différence n'est pas esthétique, elle est financière : moins de ressources consommées signifie une facture cloud moins élevée et une infrastructure plus stable.
La confusion entre les types DATE et DATETIME
Beaucoup pensent que SQL va automatiquement convertir les types de données de manière transparente. C'est une hypothèse dangereuse. Si vous comparez une chaîne de caractères "2024-05-01" avec une colonne de type DATETIME, certains moteurs de base de données vont faire des suppositions risquées.
Dans mon expérience, j'ai vu des systèmes où l'omission des secondes entraînait des résultats incohérents selon que le client SQL était configuré en format européen ou américain. Si votre base s'attend à du ISO 8601 et que vous lui envoyez un format ambigu, vous risquez de filtrer sur le 5 janvier au lieu du 1er mai. Il ne faut jamais laisser la base de données deviner vos intentions. Utilisez toujours le format YYYY-MM-DD HH:MM:SS pour vos paramètres de recherche. C'est le seul format universel qui ne vous trahira pas.
Le danger caché des dates futures et des valeurs NULL
On oublie souvent que les dates peuvent être NULL ou situées dans le futur à cause d'erreurs de saisie ou de logique applicative. Si vous cherchez des données "entre deux dates", que faites-vous des lignes où la date est absente ? Par défaut, elles sont exclues. Mais dans un processus métier, une date de livraison NULL signifie souvent que le produit n'est pas encore arrivé, pas qu'il n'existe pas.
Une autre erreur classique consiste à ne pas borner la date de fin. Si vous demandez tout ce qui est postérieur à une date donnée sans mettre de limite supérieure, vous pourriez ramasser des données de test datées de l'an 9999 qui vont fausser vos moyennes et vos agrégations. C'est un cas d'école dans les bases de données héritées où des développeurs ont utilisé des dates "sentinelles" très éloignées dans le futur au lieu de gérer les valeurs NULL proprement.
Nettoyer avant de filtrer
Avant même de lancer votre recherche, vous devez savoir comment votre système gère l'absence de données. Si vous faites un rapport de performance, exclure les NULL est probablement correct. Mais si vous faites un inventaire, oublier les NULL est une faute professionnelle. Il faut systématiquement inclure une vérification "OR date IS NULL" ou utiliser une fonction COALESCE pour attribuer une date par défaut lors de la comparaison si le métier l'exige.
Vérification de la réalité
Travailler avec les dates en SQL n'est pas une question de syntaxe, c'est une question de rigueur mathématique et de compréhension physique du stockage des données. Si vous cherchez un raccourci magique ou une fonction miracle qui fera le travail à votre place, vous allez échouer. La réalité, c'est que la gestion des dates est ingrate. Elle demande de tester vos requêtes avec des données limites : le premier du mois à minuit, le dernier du mois à 23:59:59, et les années bissextiles.
Personne ne vous félicitera quand vos rapports seront justes, car c'est ce qu'on attend de vous. Par contre, on ne vous ratera pas quand vous aurez oublié les transactions de la dernière heure du trimestre parce que vous avez eu la flemme de décomposer vos conditions de filtrage. Le succès avec les bases de données ne vient pas de la complexité de vos scripts, mais de votre capacité à anticiper comment les données vont se comporter quand vous ne les regardez pas. Ne faites pas confiance aux prétendues simplifications des ORM ou des outils de business intelligence. Vérifiez toujours le code SQL brut généré. Si vous voyez un BETWEEN sur des colonnes temporelles, vous avez une bombe à retardement entre les mains. À vous de voir si vous voulez la désamorcer maintenant ou attendre qu'elle explose pendant votre prochaine présentation budgétaire.
