Lors du développement de systèmes de paiement ou de commerce électronique, avez-vous déjà envisagé d’utiliser FLOAT ou DOUBLE pour les champs de montant de la base de données ?
Si c’est le cas, arrêtez-vous tout de suite ! Votre système pourrait perdre de l’argent secrètement.
Pourquoi les nombres à virgule flottante sont-ils interdits dans les systèmes financiers ? Une erreur de précision apparemment insignifiante, accumulée au fil d’énormes volumes de transactions et avec le temps, pourrait conduire à des catastrophes irréversibles.
Alors, que devrions-nous utiliser exactement pour stocker de l’argent ?
Pourquoi FLOAT est-il toxique pour les systèmes financiers ?
Dans le monde informatique, les nombres sont représentés en binaire. FLOAT (nombres à virgule flottante), lors de la représentation de certaines fractions décimales, est en fait une “approximation”. C’est comme essayer de couper un gâteau délicat avec une tronçonneuse grossière ; peu importe à quel point vous êtes prudent, quelques miettes tomberont toujours des bords.
L’exemple classique est : 0.1 + 0.2 ne correspond souvent pas à 0.3 dans un ordinateur. Si vous traitez des millions de transactions, ces minuscules erreurs de “0.00000000000000004” s’accumuleront, et les grands livres ne s’équilibreront jamais. N’oubliez pas :
Quand il s’agit d’argent, toute “approximation” est un désastre.
Le grand livre précis du comptable : les avantages de DECIMAL
Si vous voulez une solution exacte où “ce que vous voyez est ce que vous obtenez”, DECIMAL est le nombre à virgule fixe (fixed-point number) natif de la base de données et la norme de l’industrie.
DECIMAL est comme le grand livre exquis entre les mains d’un comptable ; il sépare précisément les nombres entiers et les décimales, garantissant que 0.1 + 0.2 est absolument égal à 0.3.
Le nombre d’or de l’industrie : DECIMAL(19, 4)
Nous recommandons généralement d’utiliser DECIMAL(19, 4) :
- 19 : Représente une capacité totale de 19 chiffres (précision).
- 4 : Indique la conservation de 4 chiffres après la virgule décimale.
Pourquoi garder 4 décimales ? Parce que lors des calculs d’intérêts, de taux d’imposition ou de taux de change, les étapes intermédiaires donnent souvent plus de 2 décimales. Réserver 2 chiffres supplémentaires comme tampon améliore la précision du calcul, et vous pouvez simplement arrondir en fonction des besoins de l’entreprise à la fin.
Cette capacité est même assez grande pour que vous puissiez acheter le PIB total de plusieurs planètes Terre !
Est-ce suffisant pour des scénarios financiers réels ?
Prenant DECIMAL(19, 4) comme exemple :
- Chiffres entiers : 15 chiffres
- Montant maximum : 999 999 999 999 999
- Conversion en USD : Env. 999 mille milliards USD
| Référence | Montant |
|---|---|
| PIB américain | Env. 27 mille milliards de dollars |
| PIB mondial total | Env. 105 mille milliards de dollars |
| Richesse mondiale totale | Env. 454 mille milliards de dollars |
DECIMAL(19, 4) peut accueillir des nombres dépassant de loin la richesse mondiale totale, ce qui est parfaitement suffisant pour la grande majorité des systèmes financiers.
Limites maximales de précision DECIMAL prises en charge par les principales bases de données
| Base de données | Précision maximale |
|---|---|
| MySQL / MariaDB | 65 |
| PostgreSQL | 131072 (chiffres entiers) + 16383 (chiffres décimaux) |
| SQL Server | 38 |
| Oracle | 38 |
La machine à jetons d’arcade : la méthode de la plus petite unité BIGINT
Si vous recherchez des performances absolues, ou si votre système a des demandes de concurrence ultra-élevées comme Stripe ou Alipay, alors BIGINT (méthode de stockage de nombres entiers) pourrait être votre meilleur choix.
Cette approche est comme la machine à jetons d’une salle d’arcade : peu importe l’argent que vous insérez, la machine le convertit en “la plus petite unité” pour le stockage. Par exemple :
- 100,50 USD → Stocké sous forme de
10050(cents) - 100 TWD → Stocké sous forme de
100(dollars)
Pourquoi choisir BIGINT ?
| Raison | Description |
|---|---|
| Vitesse ultra-rapide | L’addition et la soustraction de nombres entiers sont des spécialités du processeur ; les performances de calcul sont généralement beaucoup plus rapides qu’avec DECIMAL. |
| Efficacité d’espace | Allocation fixe de 8 octets, très adaptée aux bases de données ultra-larges. |
Cependant, l’inconvénient est une moins bonne lisibilité. Lorsque vous ouvrez la base de données et voyez 10050, vous devez le diviser automatiquement par 100 dans votre tête (ou dans votre code).
L’épreuve de force ultime : comment choisir ?
Pour décider lequel utiliser, nous pouvons prendre en compte la “fréquence des requêtes” et “l’échelle du système” :
| Dimension de comparaison | DECIMAL | BIGINT |
|---|---|---|
| Lisibilité | Excellente (lire les chiffres directement) | Moins bonne (nécessite une conversion manuelle) |
| Vitesse de calcul | Régulière | Extrêmement rapide |
| Scénarios applicables | ERP, systèmes financiers internes, commerce électronique général | Trading haute fréquence, très grands microservices, API de style Stripe |
Recommandations pragmáticas
| Scénario applicable | Champ recommandé |
|---|---|
| E-commerce général, systèmes de reporting internes d’entreprise, où les comptables doivent exécuter SQL directement pour les audits | DECIMAL(19, 4) |
| Systèmes de trading haute fréquence ou exigences d’évolutivité extrêmes | BIGINT |
Résumé
En bref, peu importe lequel vous choisissez, il est absolument et définitivement interdit d’utiliser FLOAT pour stocker de l’argent ! Choisir le type de champ approprié garantit que votre système reste solide comme un roc dans les calculs financiers.