Réponse.

En SQL, il existe plusieurs types de données principaux : chaînes (par exemple, VARCHAR, CHAR, TEXT), numériques (INT, DECIMAL, FLOAT), dates et heures (DATE, TIMESTAMP). Il est très important de choisir le type le plus petit approprié pour les données spécifiques afin d'économiser de l'espace et d'optimiser l'indexation. Une erreur courante consiste à choisir un type avec une longueur excessive (par exemple, VARCHAR(255) au lieu de VARCHAR(50)), ce qui peut entraîner des coûts de ressources inutiles.

Une autre différence importante concerne les types numériques : FLOAT stocke des valeurs approximatives, tandis que DECIMAL stocke des valeurs exactes, utile pour les opérations financières. La comparaison de chaînes de différentes codifications, par exemple, peut donner des résultats inattendus si l'on ne prend pas en compte COLLATE.

Exemple :

-- Exemple de travail avec l'incompatibilité des types
declare @price varchar(10) = '100.99';
select @price + 1;
-- Erreur : impossible d'additionner une chaîne et un nombre
-- Sans conversion explicite des types, cela ne fonctionnera pas

Question piège.

Question : Que se passe-t-il si l'on compare un champ de type VARCHAR avec un nombre ? Par exemple : WHERE code = 123 ? L'index fonctionnera-t-il rapidement ?

Réponse : SQL tentera de convertir le nombre en chaîne et de le comparer comme des chaînes. Cependant, si un index numérique a été construit sur ce champ, il ne sera pas utilisé lors de la comparaison de chaînes, et la requête ralentira. Il est recommandé d'utiliser toujours un type de donnée strict et une conversion explicite si nécessaire.

Exemple :

SELECT * FROM products WHERE code = '123'; -- L'index peut être utilisé
SELECT * FROM products WHERE code = 123;   -- L'index NE sera PAS utilisé, un full scan est possible

---

Histoire

Dans un magasin en ligne, le champ "prix" était stocké sous forme de VARCHAR pour prendre en charge différents formats de devises. Après quelques années, il a fallu trier les produits par prix : le tri ne fonctionnait pas correctement et l'indexation était impossible. Une migration complexe et une conversion des types ont été nécessaires, ce qui a pris des semaines.

Histoire

Dans une banque, un développeur a utilisé le type FLOAT pour stocker des montants. Lors des rapports, des divergences sont survenues en raison d'arrondissements, ce qui a conduit à des erreurs significatives dans la distribution des primes un an plus tard.

Histoire

Dans les logs d'une startup, la date et l'heure étaient enregistrées sous forme de texte (VARCHAR). Lorsqu'il a fallu calculer des intervalles, il s'est avéré que le temps était partout dans des formats différents, et les calculations nécessitaient un parsing normalisant coûteux en travail, ce qui a eu un impact négatif sur la performance.