Sollten Sie die Datentypen MONEY oder DECIMAL (x, y) in SQL Server auswählen?

Ich bin gespannt, ob es einen echten Unterschied zwischen dem moneyDatentyp und so etwas gibt decimal(19,4)(was Geld intern verwendet, glaube ich).

Mir ist bekannt, dass dies moneyspezifisch für SQL Server ist. Ich möchte wissen, ob es einen zwingenden Grund gibt, einen über den anderen zu wählen. Die meisten SQL Server-Beispiele (z. B. die AdventureWorks-Datenbank) verwenden moneyund nicht decimalfür Dinge wie Preisinformationen.

Sollte ich den Gelddatentyp einfach weiter verwenden, oder hat die Verwendung von Dezimalzahlen einen Vorteil? Geld besteht aus weniger Zeichen, aber das ist kein gültiger Grund :)

Niemals sollten Sie Geld verwenden. Es ist nicht genau und es ist reiner Müll; Verwenden Sie immer dezimal / numerisch.

Führen Sie dies aus, um zu sehen, was ich meine:

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

Ausgabe: 2949.0000 2949.8525

Zu einigen Leuten, die sagten, dass Sie Geld nicht durch Geld teilen:

Hier ist eine meiner Fragen zur Berechnung von Korrelationen, und die Änderung in Geld führt zu falschen Ergebnissen.

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 sagte, Geld sei ungenau. Aber Sie multiplizieren / teilen Geld nicht durch Geld! Wie viel kostet 3 Dollar mal 50 Cent? 150 Dollar? Sie multiplizieren / dividieren Geld durch Skalare, die dezimal sein sollten.

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

Ergebnisse im richtigen Ergebnis:

Geldergebnis numerisches Ergebnis
--------------------- ----------------------------- ----------
2949,8525 2949,8525

moneyist gut, solange Sie nicht mehr als 4 Dezimalstellen benötigen und sicherstellen, dass Ihre Skalare - die kein Geld darstellen - decimals sind.

Alles ist gefährlich, wenn Sie nicht wissen, was Sie tun

Selbst hochpräzise Dezimaltypen können den Tag nicht retten:

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

1.000000 <- Sollte 0.6000000 sein

Die moneyTypen sind ganze Zahlen

Die Textdarstellungen von smallmoneyund decimal(10,4)mögen gleich aussehen, aber das macht sie nicht austauschbar. Erschrecken Sie, wenn Sie Daten als gespeichert sehen varchar(10)? Das ist das gleiche.

Hinter den Kulissen sind money/ smallmoneynur ein bigint/ int Der Dezimalpunkt in der Textdarstellung von moneyist visueller Flaum, genau wie die Bindestriche in einem JJJJ-MM-TT-Datum. SQL speichert diese nicht intern.

Wählen Sie in Bezug auf decimalvs money, was für Ihre Bedürfnisse geeignet ist. Die moneyTypen existieren, weil das Speichern von Abrechnungswerten als ganzzahlige Vielfache von 1/10000 der Einheit sehr häufig ist. Wenn Sie mit tatsächlichem Geld und Berechnungen zu tun haben, die über das einfache Addieren und Subtrahieren hinausgehen, sollten Sie dies nicht auf Datenbankebene tun! Führen Sie dies auf Anwendungsebene mit einer Bibliothek durch, die Banker's Rounding (IEEE 754) unterstützt.

Mir ist klar, dass WayneM erklärt hat, dass er weiß, dass Geld spezifisch für SQL Server ist. Er fragt jedoch, ob es Gründe gibt, Geld über Dezimalzahl zu verwenden oder umgekehrt, und ich denke, ein offensichtlicher Grund sollte noch angegeben werden, und die Verwendung von Dezimalzahl bedeutet, dass Sie sich weniger Sorgen machen müssen, wenn Sie jemals Ihr DBMS ändern müssen - was passieren kann.

Machen Sie Ihre Systeme so flexibel wie möglich!

Nun, ich mag MONEY! Es ist ein Byte billiger als DECIMALund die Berechnungen werden schneller ausgeführt, da Additions- und Subtraktionsoperationen (unter dem Deckmantel) im Wesentlichen ganzzahlige Operationen sind. Das Beispiel von @ SQLMenace - eine großartige Warnung für INTUnbewusste - könnte auch auf Eger angewendet werden, bei denen das Ergebnis Null wäre. Dies ist jedoch kein Grund, gegebenenfalls keine Ganzzahlen zu verwenden .

Es ist also absolut "sicher" und angemessen zu verwenden, MONEYwenn es sich um das handelt, womit Sie es zu tun haben, MONEYund es gemäß den folgenden mathematischen Regeln zu verwenden (wie bei INTeger).

Wäre es besser gewesen, wenn SQL Server die Division und Multiplikation von MONEY's in DECIMALs (oder FLOATs?) Gefördert hätte - möglicherweise, aber sie haben sich nicht dafür entschieden; Sie haben sich auch nicht dafür entschieden, INTEger zu FLOATs zu befördern, wenn sie sie teilen.

MONEYhat kein Präzisionsproblem; Dass DECIMALein größerer Zwischentyp bei Berechnungen verwendet wird, ist nur ein "Merkmal" der Verwendung dieses Typs (und ich bin mir nicht sicher, wie weit sich dieses "Merkmal" erstreckt).

Um die spezifische Frage zu beantworten, ein "zwingender Grund"? Nun, wenn Sie in eine absolute Höchstleistung wollen , SUM(x)wo xkönnte entweder DECIMALoder MONEY, dann MONEYwird die Nase vorn haben.

Vergessen Sie auch nicht, dass es ein kleinerer Cousin ist - SMALLMONEYnur 4 Bytes, aber es ist maximal 214,748.3647- was für Geld ziemlich klein ist - und daher oft nicht gut passt.

Wenn Sie das Intermediate explizit einer Variablen zuweisen, tritt DECIMALdas gleiche Problem auf, um die Verwendung größerer Zwischentypen zu beweisen :

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

Produziert 2950.0000(okay, also zumindest DECIMALgerundet anstatt MONEYabgeschnitten - genau wie eine ganze Zahl.)

Wir sind gerade auf ein sehr ähnliches Problem gestoßen, und ich bin jetzt ein +1, weil ich Geld nur in Präsentationen auf oberster Ebene verwendet habe. Wir haben mehrere Tabellen (effektiv einen Verkaufsgutschein und eine Verkaufsrechnung), von denen jede aus historischen Gründen ein oder mehrere Geldfelder enthält, und wir müssen eine anteilige Berechnung durchführen, um herauszufinden, wie viel von der gesamten Rechnungssteuer für jede relevant ist Zeile auf dem Verkaufsgutschein. Unsere Berechnung ist

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

Dies führt zu einer realen Geld / Geld-Berechnung, die Skalierungsfehler im Teilungsteil verursacht, die sich dann zu einem falschen Mehrwertsteuerverhältnis multiplizieren. Wenn diese Werte anschließend addiert werden, erhalten wir eine Summe der Mehrwertsteueranteile, die sich nicht zum Gesamtrechnungswert addieren. Wäre einer der Werte in den Klammern eine Dezimalzahl gewesen (ich werde einen davon als solchen umwandeln), wäre der Mehrwertsteueranteil korrekt.

Wenn die Klammern ursprünglich nicht da waren, funktionierte dies früher, ich denke, aufgrund der größeren Werte simulierte es effektiv eine höhere Skala. Wir haben die Klammern hinzugefügt, weil zuerst die Multiplikation durchgeführt wurde, was in einigen seltenen Fällen die für die Berechnung verfügbare Genauigkeit beeinträchtigte, aber dies hat jetzt diesen viel häufigeren Fehler verursacht.

Als Gegenpol zur allgemeinen Ausrichtung der anderen Antworten. Sehen Sie die vielen Vorteile von Geld… Datentyp! im SQLCAT-Handbuch zur relationalen Engine

Insbesondere möchte ich auf Folgendes hinweisen

Bei der Implementierung von Kunden haben wir einige interessante Leistungszahlen für den Gelddatentyp gefunden. Wenn beispielsweise Analysis Services auf den Währungsdatentyp (von double) eingestellt wurde, um dem SQL Server-Gelddatentyp zu entsprechen, wurde die Verarbeitungsgeschwindigkeit (Zeilen / Sek.) Um 13% verbessert. Um eine schnellere Leistung in SQL Server Integration Services (SSIS) zu erzielen und 1,18 TB in weniger als 30 Minuten zu laden, wurde in SSIS 2008 - Weltrekord-ETL-Leistung festgestellt, dass die vier Dezimalspalten (9,2) mit einer Größe von geändert wurden 5 Bytes in der TPC-H LINEITEM-Tabelle zu Geld (8 Bytes) verbesserten die Geschwindigkeit beim Einfügen von Massen um 20% ... Der Grund für die Leistungsverbesserung liegt im TDS-Protokoll (Tabular Data Stream) von SQL Server. Das Prinzip des Schlüsselentwurfs besteht darin, Daten in kompakter binärer Form und so nah wie möglich am internen Speicherformat von SQL Server zu übertragen. Empirisch wurde dies während des SSIS 2008 - Weltrekord-ETL-Leistungstests mit Kernrate beobachtet; Das Protokoll fiel erheblich ab, als der Datentyp von Dezimal auf Geld umgestellt wurde. Dies macht die Datenübertragung so effizient wie möglich. Ein komplexer Datentyp benötigt zusätzliche Analyse- und CPU-Zyklen als ein Typ mit fester Breite.

Die Antwort auf die Frage lautet also "es kommt darauf an". Sie müssen bei bestimmten arithmetischen Operationen vorsichtiger sein, um die Präzision zu erhalten. Möglicherweise ist dies jedoch aufgrund von Leistungsaspekten sinnvoll.

Ich möchte eine andere Sicht auf GELD vs. NUMERISCH geben, die größtenteils auf meinem eigenen Fachwissen und meiner Erfahrung beruht ... Mein Standpunkt hier ist GELD, weil ich lange Zeit damit gearbeitet habe und NUMERISCH nie wirklich viel benutzt habe. .

GELD Pro:

• Native Datentyp . Es verwendet einen nativen Datentyp ( Ganzzahl ) wie ein CPU-Register (32 oder 64 Bit), sodass für die Berechnung kein unnötiger Overhead erforderlich ist, sodass sie kleiner und schneller ist . GELD benötigt 8 Byte und NUMERICAL (19, 4) ) benötigt 9 Bytes (12,5% größer) ...

  GELD ist schneller, solange es verwendet wird (als Geld). Wie schnell? Mein einfacher SUMTest mit 1 Million Daten zeigt, dass GELD 275 ms und NUMERIC 517 ms beträgt ... Das ist fast doppelt so schnell ... Warum SUM-Test? Siehe nächster Pro- Punkt

• Am besten für Geld . GELD eignet sich am besten zum Speichern von Geld und für Operationen, beispielsweise in der Buchhaltung. Ein einzelner Bericht kann nach Abschluss der SUM-Operation Millionen von Ergänzungen (SUM) und einige Multiplikationen ausführen. Für sehr große Buchhaltungsanwendungen ist es fast doppelt so schnell und äußerst bedeutsam ...
• Geringe Geldpräzision . Geld im wirklichen Leben muss nicht sehr genau sein. Ich meine, viele Leute interessieren sich vielleicht für 1 Cent USD, aber wie wäre es mit 0,01 Cent USD? In meinem Land kümmern sich Banken nicht mehr um Cent (Ziffer nach Dezimalkomma). Ich weiß nichts über die US-Bank oder ein anderes Land ...

GELD Con:

• Begrenzte Präzision . GELD hat nur eine Genauigkeit von vier Ziffern (nach dem Komma), daher muss es konvertiert werden, bevor Operationen wie Division ausgeführt werden ... Aber andererseits moneymuss es nicht so präzise sein und soll als Geld verwendet werden, nicht nur als a Nummer...

Aber ... Groß, aber hier ist sogar Ihre Anwendung mit echtem Geld verbunden, aber verwenden Sie sie nicht in vielen SUM-Operationen, wie in der Buchhaltung. Wenn Sie stattdessen viele Divisionen und Multiplikationen verwenden, sollten Sie kein GELD verwenden ...

Alle vorherigen Beiträge bringen gültige Punkte, aber einige beantworten die Frage nicht genau.

Die Frage ist: Warum sollte jemand Geld bevorzugen, wenn wir bereits wissen, dass es sich um einen weniger genauen Datentyp handelt, der bei komplexen Berechnungen Fehler verursachen kann?

Sie verwenden Geld, wenn Sie keine komplexen Berechnungen durchführen und diese Präzision gegen andere Anforderungen eintauschen können.

Zum Beispiel, wenn Sie diese Berechnungen nicht durchführen müssen und Daten aus gültigen Währungstextzeichenfolgen importieren müssen. Diese automatische Konvertierung funktioniert nur mit dem Datentyp MONEY:

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

Ich weiß, dass Sie Ihre eigene Importroutine erstellen können. Manchmal möchten Sie jedoch keine Importroutine mit weltweit spezifischen Gebietsschemaformaten neu erstellen.

Ein weiteres Beispiel, wenn Sie diese Berechnungen nicht durchführen müssen (Sie müssen nur einen Wert speichern) und 1 Byte sparen müssen (Geld benötigt 8 Byte und Dezimalzahl (19,4) 9 Byte). In einigen Anwendungen (schnelle CPU, großer Arbeitsspeicher, langsame E / A), wie z. B. das Lesen großer Datenmengen, kann dies auch schneller sein.

Sie sollten kein Geld verwenden, wenn Sie Multiplikationen / Divisionen für den Wert durchführen müssen. Geld wird auf die gleiche Weise gespeichert wie eine Ganzzahl, während Dezimalstellen als Dezimalpunkt und Dezimalstellen gespeichert werden. Dies bedeutet, dass das Geld in den meisten Fällen an Genauigkeit verliert, während die Dezimalzahl dies nur tut, wenn sie wieder auf die ursprüngliche Skala zurückgesetzt wird. Geld ist ein Fixpunkt, daher ändert sich seine Skala während der Berechnungen nicht. Da es sich jedoch um einen festen Punkt handelt, wenn er als Dezimalzeichenfolge gedruckt wird (im Gegensatz zu einer festen Position in einer Zeichenfolge der Basis 2), werden Werte bis zur Skala von 4 genau dargestellt. Für Addition und Subtraktion ist Geld also in Ordnung.

Eine Dezimalstelle wird intern in der Basis 10 dargestellt, und daher basiert die Position des Dezimalpunkts auch auf der Basis 10-Zahl. Wodurch sein Bruchteil seinen Wert genau darstellt, genau wie bei Geld. Der Unterschied besteht darin, dass Zwischenwerte der Dezimalzahl eine Genauigkeit von bis zu 38 Stellen beibehalten können.

Bei einer Gleitkommazahl wird der Wert binär wie eine Ganzzahl gespeichert, und die Position des Dezimalpunkts (oder Binärpunkts) ist relativ zu den Bits, die die Zahl darstellen. Da es sich um einen binären Dezimalpunkt handelt, verlieren Basis-10-Zahlen direkt nach dem Dezimalpunkt an Genauigkeit. 1/5 oder 0,2 kann auf diese Weise nicht genau dargestellt werden. Weder Geld noch Dezimalstellen leiden unter dieser Einschränkung.

Es ist einfach genug, Geld in Dezimalzahlen umzuwandeln, die Berechnungen durchzuführen und den resultierenden Wert dann wieder in einem Geldfeld oder einer Geldvariablen zu speichern.

Von meinem POV möchte ich, dass Dinge, die mit Zahlen passieren, einfach passieren, ohne dass ich zu viel darüber nachdenken muss. Wenn alle Berechnungen in Dezimalzahlen konvertiert werden sollen, möchte ich für mich nur Dezimalzahlen verwenden. Ich würde das Geldfeld für Anzeigezwecke speichern.

In Bezug auf die Größe sehe ich nicht genug Unterschiede, um meine Meinung zu ändern. Geld benötigt 4 - 8 Bytes, während Dezimal 5, 9, 13 und 17 sein kann. Die 9 Bytes können den gesamten Bereich abdecken, den die 8 Bytes Geld können. Indexweise (Vergleichen und Suchen sollten vergleichbar sein).

Ich habe einen Grund gefunden, Dezimal über Geld in Bezug auf Genauigkeit zu verwenden.

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

Testen Sie es einfach und treffen Sie Ihre Entscheidung.

Ich habe gerade diesen Blogeintrag gesehen: Money vs. Decimal in SQL Server .

Was im Grunde sagt, dass Geld ein Präzisionsproblem hat ...

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

set @m = 19.34
set @d = 19.34

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

Für den moneyTyp erhalten Sie 19.30 statt 19.34. Ich bin nicht sicher, ob es ein Anwendungsszenario gibt, das Geld zur Berechnung in 1000 Teile aufteilt, aber dieses Beispiel weist einige Einschränkungen auf.