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

Question

Ich bin neugierig, ob es einen wirklichen Unterschied gibt zwischen dem money Datentyp und etwas wie decimal(19,4) (das ist das, was Geld intern verwendet, glaube ich).

Ich bin mir bewusst, dass money ist spezifisch für SQL Server. Ich möchte wissen, ob es einen zwingenden Grund gibt, das eine dem anderen vorzuziehen; die meisten SQL Server-Beispiele (z. B. die AdventureWorks-Datenbank) verwenden money でなく decimal für Dinge wie Preisinformationen.

Sollte ich einfach weiterhin den Datentyp "Geld" verwenden, oder gibt es einen Vorteil, wenn ich stattdessen "Dezimal" verwende? Bei Geld sind weniger Zeichen einzugeben, aber das ist kein triftiger Grund :)

Answer 1

Wir sind gerade auf ein sehr ähnliches Problem gestoßen, und ich bin jetzt sehr dafür, Geld nur noch bei Präsentationen auf höchster Ebene zu verwenden. Wir haben mehrere Tabellen (effektiv einen Verkaufsbeleg und eine Verkaufsrechnung), von denen jede aus historischen Gründen ein oder mehrere Money-Felder enthält, und wir müssen eine anteilige Berechnung durchführen, um herauszufinden, wie viel der gesamten Rechnungssteuer für jede Zeile des Verkaufsbelegs relevant ist. Unsere Berechnung lautet

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

Dies führt zu einer realen Geld/Geld-Berechnung, die Skalenfehler bei der Division verursacht, die sich dann zu einem falschen Mehrwertsteueranteil multiplizieren. Wenn diese Werte anschließend addiert werden, ergibt sich eine Summe der MwSt.-Anteile, die nicht dem Gesamtwert der Rechnung entspricht. Wäre einer der beiden Werte in den Klammern ein Dezimalwert (ich bin dabei, einen von ihnen als Dezimalwert zu berechnen), wäre der Mehrwertsteueranteil korrekt.

Als die Klammern noch nicht vorhanden waren, funktionierte die Berechnung. Ich vermute, dass sie aufgrund der größeren Werte effektiv eine höhere Skala simulierte. Wir fügten die Klammern hinzu, weil zuerst die Multiplikation durchgeführt wurde, was in einigen seltenen Fällen die für die Berechnung verfügbare Genauigkeit sprengte, aber das hat jetzt diesen viel häufigeren Fehler verursacht.

Answer 2

Als Gegenargument zum allgemeinen Tenor der anderen Antworten. Siehe Die vielen Vorteile von Geld Datentyp! en SQLCATs Leitfaden zur relationalen Maschine

Konkret möchte ich auf Folgendes hinweisen

Bei der Arbeit an Kundenimplementierungen haben wir einige interessante Leistungszahlen in Bezug auf den Datentyp Geld. Zum Beispiel, wenn Analysis Services auf den Datentyp "Währung" (von "double") gesetzt wurde, um Geld-Datentyp des SQL Servers anzupassen, gab es eine 13%ige Verbesserung in der Verarbeitungsgeschwindigkeit (Zeilen/Sek.). Um eine schnellere Leistung innerhalb von SQL Server Integration Services (SSIS) zu erhalten, um 1,18 TB in weniger als dreißig Minuten zu erreichen, wie in SSIS 2008 - Weltrekord bei der ETL-Leistung vermerkt, wurde wurde festgestellt, dass das Ändern der vier Dezimal(9,2)-Spalten mit einer Größe von 5 Bytes in der TPC-H LINEITEM-Tabelle in Geld (8 Bytes) geändert wurden, was die Einfügegeschwindigkeit um 20 % verbesserte ... Der Grund für die Leistungsverbesserung liegt im TDS-Protokoll (Tabular Data Stream) von SQL Server, das Daten in kompakter binärer Form und so nah wie möglich an das interne Speicherformat von SQL Server Format von SQL Server. Empirisch wurde dies während des SSIS 2008 - Weltrekord-ETL-Leistungstests mit Kernrate; das Protokoll fiel deutlich ab, als der Datentyp von Dezimal auf Geld umgestellt wurde. Dies macht die Übertragung von Daten so effizient wie möglich. Ein komplexer Datentyp erfordert mehr Parsing und CPU-Zyklen als ein Typ mit fester Breite.

Die Antwort auf die Frage lautet also "es kommt darauf an". Bei bestimmten arithmetischen Operationen müssen Sie vorsichtiger sein, um die Genauigkeit zu wahren, aber vielleicht lohnt sich dies aus Leistungsgründen.

Answer 3

Ich möchte eine andere Sichtweise von GELD vs. NUMERISCH geben, die weitgehend 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...

MONEY Pro:

• Einheimischer Datentyp . Es verwendet einen nativen Datentyp ( Ganzzahl ) als das gleiche wie ein CPU-Register (32 oder 64 Bit), so dass die Berechnung keinen unnötigen Overhead benötigt und es ist kleiner y schneller ... MONEY benötigt 8 Bytes und NUMERICAL(19, 4) benötigt 9 Bytes (12,5% mehr)...

  GELD ist schneller, solange es für seinen eigentlichen Zweck (als Geld) verwendet wird. Wie schnell? Meine einfache SUM Ein Test mit 1 Million Daten zeigt, dass MONEY 275 ms und NUMERIC 517 ms braucht... Das ist fast doppelt so schnell ... Warum SUM-Test? Siehe nächstes Pro Punkt

• Das Beste fürs Geld . MONEY eignet sich am besten für die Aufbewahrung von Geld und die Durchführung von Operationen, zum Beispiel in der Buchhaltung. Ein einziger Bericht kann Millionen von Additionen (SUM) und ein paar Multiplikationen nach der SUM-Operation ausführen. Für sehr große Buchhaltungsanwendungen ist es fast doppelt so schnell und es ist von großer Bedeutung...

• Geringe Präzision des Geldes . Geld muss im wirklichen Leben nicht sehr genau sein. Ich meine, viele Leute mögen sich um 1 Cent USD kümmern, aber wie sieht es mit 0,01 Cent USD aus? In meinem Land kümmern sich die Banken nicht mehr um Cents (Ziffer nach dem Komma); ich weiß nicht, wie es bei US-Banken oder in anderen Ländern ist...

MONEY Con:

• Begrenzte Präzision . MONEY hat nur eine Genauigkeit von vier Ziffern (nach dem Komma), so dass es umgewandelt werden muss, bevor Operationen wie Divisionen durchgeführt werden... Aber dann wiederum money muss nicht so genau sein und ist als Geld gedacht, nicht nur als Zahl...

Aber... Groß, aber hier ist auch Ihre Anwendung beteiligt Echtgeld, aber nicht in vielen SUM-Operationen verwenden, wie in der Buchhaltung. Wenn du stattdessen viele Divisionen und Multiplikationen verwendest, dann solltest du MONEY nicht benutzen...

Answer 4

Alle bisherigen Beiträge enthalten stichhaltige Argumente, aber einige beantworten die Frage nicht genau.

Die Frage ist: Warum sollte jemand Geld bevorzugen, wenn wir bereits wissen, dass es ein ungenauer Datentyp ist und bei komplexen Berechnungen Fehler verursachen kann?

Sie verwenden Geld, wenn Sie keine komplizierten Berechnungen anstellen müssen und diese Präzision für andere Bedürfnisse nutzen können.

Zum Beispiel, wenn Sie diese Berechnungen nicht durchführen müssen, sondern Daten aus gültigen Währungstextzeichenfolgen importieren wollen. 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. Aber manchmal möchte man eine Importroutine mit weltweit spezifischen Gebietsschemaformaten nicht neu erstellen.

Ein anderes Beispiel: Sie müssen diese Berechnungen nicht durchführen (Sie brauchen nur einen Wert zu speichern) und müssen 1 Byte einsparen (Geld benötigt 8 Byte und decimal(19,4) benötigt 9 Byte). Bei einigen Anwendungen (schnelle CPU, großer Arbeitsspeicher, langsame IO), z. B. beim Lesen großer Datenmengen, kann dies ebenfalls schneller sein.

Answer 5

Ich habe einen Grund für die Verwendung von Dezimalzahlen anstelle von Geldbeträgen im Fach Genauigkeit gefunden.

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.