Bester Datentyp zum Speichern von Geldwerten in MySQL

Ich möchte viele Datensätze in einer MySQL-Datenbank speichern. Alle von ihnen enthalten Geldwerte. Aber ich weiß nicht, wie viele Ziffern für jede eingefügt werden.
Welchen Datentyp muss ich dafür verwenden?
VARCHAR oder INT (oder andere numerische Datentypen)?

Da Geld eine genaue Darstellung benötigt, verwenden Sie keine Datentypen, die nur ungefähr sind float. Sie können dafür einen numerischen Festkomma-Datentyp verwenden

decimal(15,2)

• 15 ist die Genauigkeit (Gesamtlänge des Wertes einschließlich Dezimalstellen)
• 2 ist die Anzahl der Nachkommastellen

Siehe MySQL Numeric Types :

Diese Typen werden verwendet, wenn es wichtig ist, die genaue Genauigkeit beizubehalten, beispielsweise bei Gelddaten .

Sie können verwenden DECIMALoder NUMERICbeide sind gleich

Die Typen DECIMAL und NUMERIC speichern exakte numerische Datenwerte. Diese Typen werden verwendet, wenn es wichtig ist, die genaue Genauigkeit beizubehalten, beispielsweise bei Gelddaten. In MySQL ist NUMERIC als DECIMAL implementiert, daher gelten die folgenden Anmerkungen zu DECIMAL gleichermaßen für NUMERIC. : MySQL

dh DECIMAL(10,2)

Gut gelesen

Ich bevorzuge es BIGINT, die Werte zu verwenden und zu speichern, indem ich sie mit 100 multipliziere , damit sie ganzzahlig werden.

Um beispielsweise einen Währungswert von darzustellen 93.49, wird der Wert als gespeichert 9349, während der Wert angezeigt wird , den wir durch 100 teilen und anzeigen können. Dies belegt weniger Speicherplatz.

Achtung:
Meistens führen wir keine currency * currencyMultiplikation durch. Wenn wir dies tun, teilen Sie das Ergebnis durch 100 und speichern Sie es, damit es wieder die richtige Genauigkeit erreicht.

Es hängt von Ihren Bedürfnissen ab.

DECIMAL(10,2)Normalerweise reicht die Verwendung aus, aber wenn Sie etwas genauere Werte benötigen, können Sie diese einstellen DECIMAL(10,4).

Wenn Sie mit großen Werten arbeiten, ersetzen Sie 10durch 19.

Wenn Ihre Anwendung Geldwerte bis zu einer Billion verarbeiten muss, sollte dies funktionieren: 13,2 Wenn Sie GAAP (General Accepted Accounting Principles) einhalten müssen, verwenden Sie: 13,4

Normalerweise sollten Sie Ihre Geldwerte bei 13,4 summieren, bevor Sie die Ausgabe auf 13,2 runden.

Dies hängt in der Tat von den Vorlieben des Programmierers ab. Ich persönlich verwende: numeric(15,4)um die allgemein anerkannten Rechnungslegungsgrundsätze ( GAAP ) einzuhalten .

Versuchen Sie es mit

Decimal(19,4)

Dies funktioniert normalerweise auch mit jeder anderen Datenbank

Wir benutzen double.

*keuchen*

Warum?

Weil es eine beliebige 15-stellige Zahl ohne Einschränkungen für den Dezimalpunkt darstellen kann . Alles für nur 8 Bytes!

So kann es darstellen:

• 0.123456789012345
• 123456789012345.0

... und alles dazwischen.

Dies ist nützlich, da es sich um globale Währungen handelt und doubledie verschiedenen Dezimalstellen gespeichert werden können, auf die wir wahrscheinlich stoßen werden.

Ein einzelnes doubleFeld kann 999.999.999.999.999 in japanischen Yen, 9.999.999.999.999,99 in US-Dollar und sogar 9.999.999.99999999 in Bitcoins darstellen

Wenn Sie versuchen, dasselbe mit zu tun decimal, benötigen Sie, decimal(30, 15)was 14 Bytes kostet.

Vorsichtsmaßnahmen

Natürlich ist die Verwendung doublenicht ohne Einschränkungen.

Allerdings ist es nicht Genauigkeitsverlust , wie einige darauf hinweisen neigen. Auch wenn doublees für das Basis-10-System intern möglicherweise nicht genau ist , können wir es genau machen, indem wir den Wert, den wir aus der Datenbank ziehen, auf seine signifikanten Dezimalstellen runden . Bei Bedarf ist das so. (zB Wenn es ausgegeben werden soll und eine Darstellung der Basis 10 erforderlich ist.)

Die Einschränkungen sind, dass wir jedes Mal, wenn wir damit rechnen, das Ergebnis normalisieren müssen (indem wir es auf seine signifikanten Dezimalstellen runden), bevor:

1. Vergleiche durchführen.
2. Schreiben Sie es zurück in die Datenbank.

Eine andere Art von Einschränkung besteht darin, dass im Gegensatz dazu, decimal(m, d)wo die Datenbank verhindert, dass Programme eine Zahl mit mehr als mZiffern einfügen , keine derartigen Überprüfungen vorhanden sind double. Ein Programm könnte einen vom Benutzer eingegebenen Wert von 20 Stellen einfügen und wird dann stillschweigend als ungenauer Betrag aufgezeichnet.

Zu der Zeit, als diese Frage gestellt wurde, dachte niemand über den Bitcoin-Preis nach. Im Fall von BTC ist die Verwendung wahrscheinlich nicht ausreichend DECIMAL(15,2). Wenn der Bitcoin auf 100.000 US-Dollar oder mehr steigt, müssen wir mindestens DECIMAL(18,9)Kryptowährungen in unseren Apps unterstützen.

DECIMAL(18,9)nimmt in MySQL 12 Bytes Speicherplatz in Anspruch ( 4 Bytes pro 9 Ziffern ).

Das Speichern von Geld BIGINTmultipliziert mit 100 oder mehr mit dem Grund, weniger Speicherplatz zu verbrauchen, macht in allen "normalen" Situationen keinen Sinn.

• Um mit GAAP in Einklang zu bleiben, reicht es aus, Währungen in zu speichern DECIMAL(13,4)
• Das MySQL-Handbuch liest, dass es 4 Bytes pro 9 Ziffern zum Speichern benötigt DECIMAL.
  • https://dev.mysql.com/doc/refman/8.0/en/precision-math-decimal-characteristics.html
• DECIMAL(13,4) repräsentiert 9 Stellen + 4 Bruchstellen (Dezimalstellen) => 4 + 2 Bytes = 6 Bytes
• Vergleiche mit 8 Bytes, die zum Speichern benötigt werden BIGINT.

Wenn GAAP-Konformität erforderlich ist oder Sie 4 Dezimalstellen benötigen:

DECIMAL (13, 4) Unterstützt einen Maximalwert von:

999.999.999.9999 USD

Andernfalls, wenn 2 Dezimalstellen ausreichen: DECIMAL (13,2)

src: https://rietta.com/blog/best-data-types-for-currencymoney-in/

Multipliziert 10000 und speichert als BIGINT, wie "Währung" in Visual Basic und Office. Siehe https://msdn.microsoft.com/en-us/library/office/gg264338.aspx