Choisir les types et représenter les retards
Objectif : Définir les types de colonnes et distinguer les données stockées des valeurs calculées.
Une colonne mal typée peut tronquer une valeur, accepter des données incohérentes ou rendre les calculs ambigus. Dans la médiathèque, vous devez notamment distinguer la date prévue de retour, la date de retour effective et la durée d’un retard.
Vous avez déjà défini les relations, les clés et les contraintes dans les leçons précédentes. Ici, vous choisissez une représentation fiable pour chaque valeur et décidez si elle doit être enregistrée ou recalculée à partir des données de l’emprunt.
Choisir un type en fonction de la valeur
Pour les identifiants, BIGINT UNSIGNED fournit une plage positive très large et s’accorde avec AUTO_INCREMENT. Les noms et titres relèvent de VARCHAR avec une longueur maximale choisie selon le domaine ; une longueur démesurée ne remplace pas une décision de modélisation. Les colonnes de date sans heure utilisent DATE, tandis que DATETIME convient si l’heure exacte d’un événement doit être conservée.
| Valeur | Type adapté | Motif |
|---|---|---|
| Identifiant généré | BIGINT UNSIGNED | Grande plage positive, sans fraction |
| Nom ou titre | VARCHAR(n) | Texte de longueur variable, limitée |
| Date de prêt ou date prévue | DATE | Jour civil, sans heure |
| Date de retour effective | DATE NULL | Absente tant que l’exemplaire n’est pas rendu |
| Nombre de jours de retard | Valeur calculée | Dépend des dates et de la règle de calcul |
Dans ce modèle, les dates de l’emprunt sont stockées dans emprunts. La date de retour effective reste NULL tant que le prêt est en cours : cette valeur signifie « inconnue ou non encore renseignée », contrairement à une date fictive comme 1000-01-01. Une valeur par défaut ne convient que si elle représente réellement une règle métier ; par exemple, DEFAULT CURRENT_DATE peut dater automatiquement la création d’un prêt, mais ne doit pas remplir la date de retour.
Enregistrer les retards, calculer leur durée
Un retard est rattaché à l’emprunt concerné et porte une date à laquelle il a été constaté. La durée, elle, dépend de la date prévue et de la date effective de retour ; la stocker séparément créerait un risque de divergence si une date change. La requête ci-dessous calcule les jours échus à la date du jour pour les emprunts non rendus. Elle utilise le modèle des tables défini dans sql/schema.sql.
-- Durée échue des emprunts non rendus, sans enregistrer un compteur redondant.
SELECT
e.emprunt_id,
e.date_retour_prevue,
DATEDIFF(CURRENT_DATE, e.date_retour_prevue) AS jours_retard
FROM emprunts AS e
WHERE e.date_retour_effective IS NULL
AND e.date_retour_prevue < CURRENT_DATE
ORDER BY e.date_retour_prevue;La requête renvoie les emprunts non rendus dont la date prévue est passée, avec le nombre de jours écoulés depuis cette date.DATEDIFF renvoie un nombre entier de jours entre deux dates. Pour un emprunt déjà rendu en retard, la date de référence devient la date effective ; pour un emprunt encore en cours, c’est la date du jour. Vous pouvez adapter le calcul sans changer le principe : garder les dates comme faits enregistrés et obtenir la durée au moment de la lecture.
Précision et limites
Une longueur de VARCHAR fixe une limite métier et technique : prévoyez une marge réaliste, puis validez les valeurs avec les contraintes appropriées. Pour une somme, MariaDB propose notamment DECIMAL(p, s), qui conserve une précision décimale définie ; un type flottant peut introduire des approximations. Pour une durée entière en jours, une colonne entière ne se justifie que si vous devez conserver un instantané historique, par exemple le nombre de jours constaté lors de la clôture d’un retard.
À retenir
- Choisissez le type selon la nature, la précision et les limites attendues pour chaque valeur.
- Distinguez une valeur absente avec NULL ; n’utilisez une valeur par défaut que si elle exprime une règle métier.
- Conservez les dates qui décrivent un emprunt et calculez sa durée de retard à partir de ces dates.
- Ne stockez une durée calculée que si vous devez préserver un instantané historique.
La prochaine étape consiste à mesurer les requêtes sur des données représentatives avant de choisir des index.