Je ne cautionne pas le "format" proposé ci dessus, même s'il y a surement des usages (bien qu'un INTEGER donc 32 ou 64b pour stocker une puissance reste quand même un poil abusé).
Par contre le double même "correctement utilisé" reste un dérivé du float, et donc une approximation du nombre d'origine via une puissance de 2 => dans tout les cas c'est inadapté à des calculs monetaires précis.
le DECIMAL() est un format de stockage et des règles de calculs adaptés au monetaire (tant que le calcul se fait dans le SGBD) similaire au format proposé dont je ne vois pas bien l'intérêt sauf pour le coté NIH peut-être ...
Si tu a vraiment besoin d'une précision à 5 ou plus chiffres après la virgule il suffit de partir sur un DECIMAL(13,5) ou plus.
[^] # Re: Monnaie = danger
Posté par -=[ silmaril ]=- (site web personnel) . En réponse au journal SQL Decimal vs Double. Évalué à 1.
Je ne cautionne pas le "format" proposé ci dessus, même s'il y a surement des usages (bien qu'un INTEGER donc 32 ou 64b pour stocker une puissance reste quand même un poil abusé).
Par contre le double même "correctement utilisé" reste un dérivé du float, et donc une approximation du nombre d'origine via une puissance de 2 => dans tout les cas c'est inadapté à des calculs monetaires précis.
le DECIMAL() est un format de stockage et des règles de calculs adaptés au monetaire (tant que le calcul se fait dans le SGBD) similaire au format proposé dont je ne vois pas bien l'intérêt sauf pour le coté NIH peut-être ...
Si tu a vraiment besoin d'une précision à 5 ou plus chiffres après la virgule il suffit de partir sur un DECIMAL(13,5) ou plus.