Devriez-vous choisir les types de données MONEY ou DECIMAL (x, y) dans SQL Server?

Je suis curieux de savoir s'il existe ou non une réelle différence entre le moneytype de données et quelque chose comme decimal(19,4)(c'est ce que l'argent utilise en interne, je crois).

Je suis conscient que moneyc'est spécifique à SQL Server. Je veux savoir s'il y a une raison impérieuse de choisir l'un plutôt que l'autre; la plupart des exemples SQL Server (par exemple la base de données AdventureWorks) utilisent moneyet non decimalpour des choses comme les informations de prix.

Dois-je simplement continuer à utiliser le type de données money, ou y a-t-il un avantage à utiliser la décimale à la place? L'argent est moins de caractères à taper, mais ce n'est pas une raison valable :)

Vous ne devez jamais utiliser d'argent. Ce n'est pas précis et ce sont des ordures pures; utilisez toujours décimal / numérique.

Exécutez ceci pour voir ce que je veux dire:

DECLARE
    @mon1 MONEY,
    @mon2 MONEY,
    @mon3 MONEY,
    @mon4 MONEY,
    @num1 DECIMAL(19,4),
    @num2 DECIMAL(19,4),
    @num3 DECIMAL(19,4),
    @num4 DECIMAL(19,4)

    SELECT
    @mon1 = 100, @mon2 = 339, @mon3 = 10000,
    @num1 = 100, @num2 = 339, @num3 = 10000

    SET @mon4 = @mon1/@mon2*@mon3
    SET @num4 = @num1/@num2*@num3

    SELECT @mon4 AS moneyresult,
    @num4 AS numericresult

Sortie: 2949.0000 2949.8525

À certaines des personnes qui ont dit que vous ne divisez pas l'argent par l'argent:

Voici l'une de mes requêtes pour calculer les corrélations, et changer cela en argent donne de mauvais résultats.

select t1.index_id,t2.index_id,(avg(t1.monret*t2.monret)
    -(avg(t1.monret) * avg(t2.monret)))
            /((sqrt(avg(square(t1.monret)) - square(avg(t1.monret))))
            *(sqrt(avg(square(t2.monret)) - square(avg(t2.monret))))),
current_timestamp,@MaxDate
            from Table1 t1  join Table1 t2  on t1.Date = traDate
            group by t1.index_id,t2.index_id

SQLMenace a déclaré que l'argent était inexact. Mais vous ne multipliez / divisez pas l'argent par l'argent! Combien coûte 3 dollars multiplié par 50 cents? 150 dollarcents? Vous multipliez / divisez l'argent par des scalaires, qui doivent être décimaux.

DECLARE
@mon1 MONEY,
@mon4 MONEY,
@num1 DECIMAL(19,4),
@num2 DECIMAL(19,4),
@num3 DECIMAL(19,4),
@num4 DECIMAL(19,4)

SELECT
@mon1 = 100,
@num1 = 100, @num2 = 339, @num3 = 10000

SET @mon4 = @mon1/@num2*@num3
SET @num4 = @num1/@num2*@num3

SELECT @mon4 AS moneyresult,
@num4 AS numericresult

Résultats dans le bon résultat:

moneyresult numericresult
--------------------- ----------------------------- ----------
2949.8525 2949.8525

moneyest bon tant que vous n'avez pas besoin de plus de 4 chiffres décimaux et que vous vous assurez que vos scalaires - qui ne représentent pas de l'argent - sont decimals.

Tout est dangereux si vous ne savez pas ce que vous faites

Même les types décimaux de haute précision ne peuvent pas sauver la situation:

declare @num1 numeric(38,22)
declare @num2 numeric(38,22)
set @num1 = .0000006
set @num2 = 1.0
select @num1 * @num2 * 1000000

1,000000 <- Devrait être 0,6000000

Les moneytypes sont des entiers

Les représentations textuelles de smallmoneyet decimal(10,4)peuvent se ressembler, mais cela ne les rend pas interchangeables. Vous grincer des dents quand vous voyez les dates stockées sous varchar(10)? C'est la même chose.

Dans les coulisses, money/ ne smallmoneysont qu'un bigint/ int La virgule décimale dans la représentation textuelle moneyest un fluff visuel, tout comme les tirets d'une date aaaa-mm-jj. SQL ne les stocke pas réellement en interne.

En ce qui concerne decimalvs money, choisissez ce qui convient à vos besoins. Les moneytypes existent car le stockage des valeurs comptables sous forme de multiples entiers de 1/10000ème d'unité est très courant. De plus, si vous traitez de l'argent réel et des calculs au-delà de la simple addition et soustraction, vous ne devriez pas le faire au niveau de la base de données! Faites-le au niveau de l'application avec une bibliothèque qui prend en charge l'arrondi bancaire (IEEE 754)

Je me rends compte que WayneM a déclaré qu'il savait que l'argent est spécifique à SQL Server. Cependant, il demande s'il y a des raisons d'utiliser de l'argent au-dessus de la décimale ou vice versa et je pense qu'une raison évidente doit encore être indiquée et que l'utilisation de la décimale signifie que c'est une chose de moins à s'inquiéter si vous devez changer votre SGBD - ce qui peut arriver.

Rendez vos systèmes aussi flexibles que possible!

Eh bien, j'aime bien MONEY! C'est un octet moins cher que DECIMAL, et les calculs sont plus rapides car (sous les couvertures) les opérations d'addition et de soustraction sont essentiellement des opérations entières. L'exemple de @ SQLMenace - qui est un grand avertissement pour les ignorants - pourrait également être appliqué aux INTegers, où le résultat serait nul. Mais ce n'est pas une raison pour ne pas utiliser d'entiers - le cas échéant .

Il est donc parfaitement «sûr» et approprié de l'utiliser MONEYlorsque vous traitez MONEYet de l'utiliser selon les règles mathématiques qu'il suit (comme INTeger).

Aurait-il été préférable que SQL Server promeuve la division et la multiplication des MONEYs en DECIMALs (ou FLOATs?) - peut-être, mais ils n'ont pas choisi de le faire; ils n'ont pas non plus choisi de promouvoir les INTegers en FLOATs lors de leur division.

MONEYn'a pas de problème de précision; cela permet DECIMALd'avoir un type intermédiaire plus grand utilisé pendant les calculs n'est qu'une «fonctionnalité» de l'utilisation de ce type (et je ne suis pas vraiment sûr de l'étendue de cette «fonctionnalité»).

Pour répondre à la question spécifique, une "raison impérieuse"? Eh bien, si vous voulez des performances maximales absolues dans un SUM(x)où xpourrait être l'un DECIMALou l' autre MONEY, alors vous MONEYaurez un avantage.

N'oubliez pas non plus qu'il s'agit d'un cousin plus petit - SMALLMONEYjuste 4 octets, mais il atteint son maximum 214,748.3647- ce qui est assez petit pour de l'argent - et n'est donc pas souvent un bon choix.

Pour prouver l'intérêt d'utiliser des types intermédiaires plus grands, si vous affectez explicitement l'intermédiaire à une variable, DECIMALle même problème se produit:

declare @a decimal(19,4)
declare @b decimal(19,4)
declare @c decimal(19,4)
declare @d decimal(19,4)

select @a = 100, @b = 339, @c = 10000

set @d = @a/@b

set @d = @d*@c

select @d

Produit 2950.0000(d'accord, donc au moins DECIMALarrondi plutôt que MONEYtronqué, comme un entier.)

Nous venons de rencontrer un problème très similaire et je suis maintenant très bien un +1 pour ne jamais utiliser Money sauf dans la présentation de haut niveau. Nous avons plusieurs tableaux (en fait un bon de vente et une facture de vente), chacun contenant un ou plusieurs champs Money pour des raisons historiques, et nous devons effectuer un calcul au prorata pour déterminer la proportion de la facture totale que la taxe est pertinente pour chacun. ligne sur le bon de vente. Notre calcul est

vat proportion = total invoice vat x (voucher line value / total invoice value)

Il en résulte un calcul réel argent / argent qui provoque des erreurs d'échelle sur la partie de division, qui se multiplient ensuite dans une proportion de TVA incorrecte. Lorsque ces valeurs sont ajoutées par la suite, nous nous retrouvons avec une somme des proportions de TVA qui ne correspondent pas à la valeur totale de la facture. Si l'une des valeurs entre parenthèses avait été décimale (je suis sur le point de transposer l'une d'entre elles en tant que telle), la proportion de TVA serait correcte.

Lorsque les crochets n'étaient pas là à l'origine, cela fonctionnait, je suppose qu'en raison des valeurs plus importantes impliquées, cela simulait effectivement une échelle plus élevée. Nous avons ajouté les crochets parce qu'il effectuait d'abord la multiplication, ce qui dans certains cas rares soufflait la précision disponible pour le calcul, mais cela a maintenant causé cette erreur beaucoup plus courante.

En contrepoint de l'orientation générale des autres réponses. Voir les nombreux avantages de l'argent… Type de données! dans le Guide du moteur relationnel de SQLCAT

Plus précisément, je voudrais souligner ce qui suit

En travaillant sur les implémentations des clients, nous avons trouvé des chiffres de performance intéressants concernant le type de données money. Par exemple, lorsque Analysis Services a été défini sur le type de données monétaire (de double) pour correspondre au type de données monétaire SQL Server, la vitesse de traitement (lignes / s) a été améliorée de 13%. Pour obtenir des performances plus rapides dans SQL Server Integration Services (SSIS) pour charger 1,18 To en moins de trente minutes, comme indiqué dans SSIS 2008 - Record record world performance ETL, il a été observé que la modification des quatre colonnes décimales (9,2) avec une taille de 5 octets dans la table TPC-H LINEITEM en argent (8 octets) ont amélioré la vitesse d'insertion en bloc de 20% ... La raison de l'amélioration des performances est due au protocole TDS (Tabular Data Stream) de SQL Server, qui a le principe de conception clé pour transférer des données sous forme binaire compacte et aussi proche que possible du format de stockage interne de SQL Server. Empiriquement, cela a été observé lors du SSIS 2008 - test de performance record mondial ETL utilisant Kernrate; le protocole a chuté de manière significative lorsque le type de données a été changé en argent à partir de décimal. Cela rend le transfert de données aussi efficace que possible. Un type de données complexe nécessite des cycles d'analyse et d'UC supplémentaires pour gérer qu'un type à largeur fixe.

La réponse à la question est donc "ça dépend". Vous devez être plus prudent avec certaines opérations arithmétiques pour préserver la précision, mais vous constaterez peut-être que des considérations de performances en valent la peine.

Je veux donner une vision différente de MONEY par rapport à NUMERICAL, en grande partie basée sur ma propre expertise et mon expérience ... Mon point de vue ici est MONEY, parce que je travaille avec lui depuis longtemps et que je n'ai jamais beaucoup utilisé NUMERICAL. .

MONEY Pro:

• Type de données natif . Il utilise un type de données natif ( entier ) identique à un registre CPU (32 ou 64 bits), donc le calcul n'a pas besoin de surcharge inutile donc il est plus petit et plus rapide ... L'ARGENT a besoin de 8 octets et NUMÉRIQUE (19, 4 ) a besoin de 9 octets (12,5% plus gros) ...

  L'ARGENT est plus rapide tant qu'il est utilisé car il devait l'être (en argent). À quelle vitesse? Mon simple SUMtest sur 1 million de données montre que MONEY est de 275 ms et NUMERIC de 517 ms ... C'est presque deux fois plus rapide ... Pourquoi le test SUM? Voir le prochain point Pro

• Meilleur pour l'argent . L'ARGENT est idéal pour stocker de l'argent et effectuer des opérations, par exemple, en comptabilité. Un seul rapport peut exécuter des millions d'ajouts (SUM) et quelques multiplications une fois l'opération SUM terminée. Pour les très grandes applications comptables, il est presque deux fois plus rapide , et il est extrêmement important ...
• Faible précision de l'argent . L'argent dans la vraie vie n'a pas besoin d'être très précis. Je veux dire, beaucoup de gens peuvent se soucier d'environ 1 cent USD, mais qu'en est-il de 0,01 cent USD? En fait, dans mon pays, les banques ne se soucient plus des cents (chiffre après virgule décimale); Je ne connais pas la banque américaine ou un autre pays ...

ARGENT Con:

• Précision limitée . L'ARGENT n'a qu'une précision de quatre chiffres (après la virgule), il doit donc être converti avant d'effectuer des opérations telles que la division ... Mais là encore, il moneyn'a pas besoin d'être aussi précis et est destiné à être utilisé comme de l'argent, pas seulement un nombre...

Mais ... Gros, mais voici même votre application impliquée en argent réel, mais ne l'utilisez pas dans de nombreuses opérations SUM, comme en comptabilité. Si vous utilisez à la place de nombreuses divisions et multiplications, vous ne devez pas utiliser ARGENT ...

Tous les messages précédents apportent des points valables, mais certains ne répondent pas précisément à la question.

La question est la suivante: pourquoi quelqu'un préférerait-il l'argent alors que nous savons déjà qu'il s'agit d'un type de données moins précis et peut provoquer des erreurs s'il est utilisé dans des calculs complexes?

Vous utilisez de l'argent lorsque vous ne ferez pas de calculs complexes et pouvez échanger cette précision pour d'autres besoins.

Par exemple, lorsque vous n'avez pas à effectuer ces calculs et que vous devez importer des données à partir de chaînes de texte de devise valides. Cette conversion automatique fonctionne uniquement avec le type de données MONEY:

SELECT CONVERT(MONEY, '$1,000.68')

Je sais que vous pouvez créer votre propre routine d'importation. Mais parfois, vous ne voulez pas recréer une routine d'importation avec des formats régionaux spécifiques au monde.

Un autre exemple, lorsque vous n'avez pas à faire ces calculs (vous avez juste besoin de stocker une valeur) et que vous devez économiser 1 octet (l'argent prend 8 octets et la décimale (19,4) prend 9 octets). Dans certaines applications (CPU rapide, grande RAM, IO lente), comme la lecture d'une énorme quantité de données, cela peut aussi être plus rapide.

Vous ne devez pas utiliser d'argent lorsque vous devez faire des multiplications / divisions sur la valeur. L'argent est stocké de la même manière qu'un entier est stocké, tandis que le nombre décimal est stocké sous la forme d'un point décimal et de chiffres décimaux. Cela signifie que l'argent perdra sa précision dans la plupart des cas, tandis que la décimale ne le fera que lorsqu'elle sera reconvertie à son échelle d'origine. L'argent est un point fixe, donc son échelle ne change pas pendant les calculs. Cependant, comme il s'agit d'un point fixe lorsqu'il est imprimé sous forme de chaîne décimale (par opposition à une position fixe dans une chaîne de base 2), les valeurs jusqu'à l'échelle de 4 sont représentées exactement. Donc, pour l'addition et la soustraction, l'argent va bien.

Une décimale est représentée en base 10 en interne, et donc la position du point décimal est également basée sur le nombre de base 10. Ce qui fait que sa partie fractionnaire représente exactement sa valeur, tout comme avec de l'argent. La différence est que les valeurs intermédiaires de décimales peuvent maintenir la précision jusqu'à 38 chiffres.

Avec un nombre à virgule flottante, la valeur est stockée en binaire comme s'il s'agissait d'un entier, et la position du point décimal (ou binaire, ahem) est relative aux bits représentant le nombre. Parce qu'il s'agit d'un point décimal binaire, les nombres en base 10 perdent leur précision juste après le point décimal. 1 / 5ème, ou 0,2, ne peut pas être représenté précisément de cette manière. Ni l'argent ni les décimales ne souffrent de cette limitation.

Il est assez facile de convertir de l'argent en décimal, d'effectuer les calculs, puis de stocker la valeur résultante dans un champ ou une variable monétaire.

De mon POV, je veux que les choses qui arrivent aux nombres se produisent sans avoir à trop y penser. Si tous les calculs vont être convertis en décimales, alors pour moi, je voudrais simplement utiliser des décimales. Je conserverais le champ de l'argent à des fins d'affichage.

En termes de taille, je ne vois pas assez de différence pour changer d'avis. L'argent prend 4 à 8 octets, tandis que la décimale peut être 5, 9, 13 et 17. Les 9 octets peuvent couvrir toute la plage que peuvent contenir les 8 octets. Par index (la comparaison et la recherche doivent être comparables).

J'ai trouvé une raison d'utiliser la décimale sur l'argent dans le sujet de précision.

DECLARE @dOne   DECIMAL(19,4),
        @dThree DECIMAL(19,4),
        @mOne   MONEY,
        @mThree MONEY,
        @fOne   FLOAT,
        @fThree FLOAT

 SELECT @dOne   = 1,
        @dThree = 3,    
        @mOne   = 1,
        @mThree = 3,    
        @fOne   = 1,
        @fThree = 3

 SELECT (@dOne/@dThree)*@dThree AS DecimalResult,
        (@mOne/@mThree)*@mThree AS MoneyResult,
        (@fOne/@fThree)*@fThree AS FloatResult

DecimalResult> 1.000000

MoneyResult> 0.9999

FloatResult> 1

Testez-le et prenez votre décision.

Je viens de voir cette entrée de blog: Money vs. Decimal dans SQL Server .

Ce qui dit essentiellement que l'argent a un problème de précision ...

declare @m money
declare @d decimal(9,2)

set @m = 19.34
set @d = 19.34

select (@m/1000)*1000
select (@d/1000)*1000

Pour le moneytype, vous obtiendrez 19.30 au lieu de 19.34. Je ne sais pas s'il existe un scénario d'application qui divise l'argent en 1000 parties pour le calcul, mais cet exemple expose certaines limites.