SQL Server MVP Steve Kass hat dieses Beispiel in den englischen Newsgroups gepostet. Es zeigt, daß der Einsatz der Datentypen zur Speicherung monetärer Daten sorgfältig durchdacht sein sollte. Man sollte stets bedenken, welche Operationen mit diesen Daten durchgeführt werden.

So ist MONEY durchaus geeignet, wenn als Rechenoperationen nur Addition und/oder Subtraktion vorkommen können. Kommen jedoch Multiplikation bzw. Division mit ins Spiel, ist der MONEY Typ mit Vorsicht zu geniessen:

declare @m1 money, @m2 money, @m3 money
declare @d1 decimal(19,4), @d2 decimal(19,4), @d3 decimal(19,4)
set @m1 = 1.00
set @m2 = 345.00
set @m3 = @m1/@m2
set @d1 = 1.00
set @d2 = 345.00
set @d3 = @d1/@d2
select @m3, @d3

                                            
--------------------- --------------------- 
.0028                 .0029

(1 row(s) affected)

Rechnet man dieses Beispiel mit Excel nach, kommt als Ergebnis 0,00289855072463768 heraus. Das Ergebnis, welches mit DECIMAL ausgewiesen wird, ist richtig und obwohl auch MONEY gemäß seiner Spezifikation "richtig" rechnet, weicht dieses Ergebnis doch um mehr als 3% ! ab.

Man kann dieses Problem "umgehen", indem man folgendes in seine Kalkulation einbaut:

declare @m1 money, @m2 money, @m3 money
declare @d1 decimal(19,4), @d2 decimal(19,4), @d3 decimal(19,4)
declare @f1 float
set @f1 = 1.0
set @m1 = 1.00
set @m2 = 345.00
set @m3 = @m1/(@m2*1.0)
set @d1 = 1.00
set @d2 = 345.00
set @d3 = @d1/@d2
select @m3, @d3
                                            
--------------------- --------------------- 
.0029                 .0029

(1 row(s) affected)

Ich würde aber stets zum DECIMAL Datentypen greifen.