Quel est le meilleur type de données pour stocker des valeurs numériques pendant des milliards de dollars avec 7 valeurs décimales dans SQL Server? Actuellement, j'utilise numérique (19, 7) Cependant, je ne sais pas si cela est correct car je n'ai pas de données pour le tester.
3 Réponses :
J'utiliserais -922,337,203 685 477.5808 à 922 337,203 685,477.5807
Cela gérera les trillions afin que vos valeurs de milliards de dollars devraient aller bien.
Référence Article: https://docs.microsoft.com/en-us/sql/t-sql/data-types/money-and-smallMoney-transact-sql?view=SQL-SERVER- 2017 argent personnellement, qui est spécialement conçu pour contenir des valeurs monétaires:
Ce serait mon premier choix également, mais OP a besoin de 7 décimales.
@Johncappelletti je vois que maintenant. La question originale n'a pas mentionné nécessitant 7 décimales, d'où ma réponse (maintenant redondante)
Merci pour votre réponse @martinparkin. Mon mauvais que je n'ai pas réalisé sa nécessité spécifique jusqu'à ce que tout le monde soit mentionné par tout le monde.
L'argent est un type de données assez effrayant pour n'importe quoi. Il peut avoir des erreurs d'arrondies. Je préférerais utiliser décimal / numérique tous les jours. Stackoverflow.com/a/582819/3813116
Merci @Seanlange, je pense que je voudrais coller à numérique (19,7) comme il semble que ce serait un pari sûr dans mon cas.
@Seanlange c'est une fois je suis en désaccord avec vous. L'argent est un type parfaitement valide. Après tout, même décimal rond ... Sélectionner une fonte (25.255 comme décimale (10,2)) = 25.26
@Johncappelletti I Globalement, évitez le type de données de l'argent de toute façon parce qu'il est exclusif. Je suppose que cela est classé comme numérique exact afin que je reste corrigé. :) Cependant, je ne vois pas l'erreur d'arrondi dans votre exemple ci-dessus. Il doit arrondi ou tronqué (ou erreur) pour s'adapter au plus petit type de données.
@Seanlange Le propriétaire est un point valide. Mon point est une précision de précision ... 25.255 n'est pas 25.26 Ce n'est pas une erreur d'arrondi, mais elle est arrondie.
@Johncappelletti accepté. Avez-vous vu l'exemple dans ce lien? Il est désactivé de 85 ¢ sur un calcul assez simple.
@Seanlange Point parfaitement valide. Je devrais peut-être adoucir ma position. :)
J'utiliserais:
pour 1 à 9 milliards décimal (12,2) ,
pour 10 à 99 milliards décimal (13,2) ,
Pour 100 à 999 milliards de décimal (14,2) .
Aucun de ces types n'a 7 décimales que l'OP demanda.
Décimal (12,2) pour les nombres 1-9 ???? L'échelle de ceux-ci est éteinte des graphiques pour les valeurs. Oh .... Peut-être que vous voulez dire 1-9 milliards?
@Seanlange oui c'est des milliards de milliards
Je t'ai eu. Ce n'est pas clair dans votre réponse du tout.
@Seanlange tu as raison!
Voulez-vous tout couvrir? Utilisez "Decimal (28,8)" Il faut 4 octets supplémentaires, mais je pense que vous ne devriez pas vous soucier de la performance / de l'espace avec ces quantités et de précision requise.
7 décimales?!? Vous avez besoin de 2 décimales pour stocker des cents.
Autre que le fait que vous n'avez pas besoin de 7 décimales pour le montant en dollars, cela tiendrait au moins 12 chiffres à gauche du point décimal.
Nous devons stocker 7 décimales, c'est pourquoi j'ai ajouté 7 décimales.
Si vous devez stocker 7 décimales, vos exigences sont déjà plus que de stocker de l'argent, ce qui nous rend difficile à répondre.
Utilisez décimal et assurez-vous de laisser suffisamment de chiffres sur la partie gauche, pas seulement pour des valeurs particulières, mais également des agrégats de mois / année, etc.
Utilisez
décimal (38, 10) . Il devrait être plus que suffisamment grand pour stocker toutes vos valeurs et vous n'avez pas à penser au type.