Geldbeträge in mysql-Datenbank abspeichern

[split.s]

Wie würdet ihr in einem Shopsystem Geldbeträge abspeichern? Welchen Spaltentyp wählt man hier am besten?

Möglichkeiten:

Sollte man die Beträge in Cent umrechnen und dann in einer INT-Spalte ablegen?

[Tom]

Hello,

Wie würdet ihr in einem Shopsystem Geldbeträge abspeichern? Welchen Spaltentyp wählt man hier am besten?

Möglichkeiten:

Sollte man die Beträge in Cent umrechnen und dann in einer INT-Spalte ablegen?

Nein. Man sollte den Spaltentyp decimal nehmen.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[split.s]

Hmmm

wenn ich dann aber 29.95 in eine DECIMAL-Spalte schreibe, wird nur 30 eingetragen! Das wars ja nicht was ich wollte

[ChrisB]

Hi,

wenn ich dann aber 29.95 in eine DECIMAL-Spalte schreibe, wird nur 30 eingetragen!

Dann machst du wohl etwas falsch.

MfG ChrisB

[Tom]

Hello,

wenn ich dann aber 29.95 in eine DECIMAL-Spalte schreibe, wird nur 30 eingetragen! Das wars ja nicht was ich wollte

Wie lautet denn das Create-Statement für die Tabelle?
Lass mal sehen!

Und wie trägst Du den Wert in die Datenbank ein?

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Vinzenz Mai]

Hallo,

wenn ich dann aber 29.95 in eine DECIMAL-Spalte schreibe, wird nur 30 eingetragen! Das wars ja nicht was ich wollte

Du solltest Deiner DECIMAL-Spalte auch die angemessene Anzahl an Nachkommastellen verpassen, wie in der Doku angegeben:

<zitat>
    When declaring a DECIMAL or NUMERIC column, the precision and scale can
    be (and usually is) specified; for example:

salary DECIMAL(5,2)
</zitat>

Freundliche Grüße

Vinzenz

[hotti]

hi Tom,

»» Wie würdet ihr in einem Shopsystem Geldbeträge abspeichern? Welchen Spaltentyp wählt man hier am besten?
»»
»» Möglichkeiten:
»»
»» Sollte man die Beträge in Cent umrechnen und dann in einer INT-Spalte ablegen?

Nein. Man sollte den Spaltentyp decimal nehmen.

Warum?

Gibt es in mysql spezielle Funktionen für Rechnungswesen/Finanzen, wo dieser Feldtyp erforderlich ist bzw. Vorteile bringt?

Viele Grüße,
Hotte

[Tom]

Hello,

»» Sollte man die Beträge in Cent umrechnen und dann in einer INT-Spalte ablegen?

Nein. Man sollte den Spaltentyp decimal nehmen.

Warum?

Gibt es in mysql spezielle Funktionen für Rechnungswesen/Finanzen, wo dieser Feldtyp erforderlich ist bzw. Vorteile bringt?

Dieser Spaltentyp garantiert den Erhalt der Digits. Es gibt also keine Darstellungsfehler duch binäre Lücken im Zahlenraum, auch nicht, wenn man rechnet.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[ChrisB]

Hi,

»» Sollte man die Beträge in Cent umrechnen und dann in einer INT-Spalte ablegen?

Nein. Man sollte den Spaltentyp decimal nehmen.

Warum?

Weil Euro-Geldbeträge nun mal üblicherweise in Euro angegeben werden, und nicht in Cent.

Gibt es in mysql spezielle Funktionen für Rechnungswesen/Finanzen, wo dieser Feldtyp erforderlich ist bzw. Vorteile bringt?

Meinst du jetzt gegenüber INT, oder gegenüber FLOAT?

Was letzteres angeht - MySQL Numeric Types:
"The FLOAT and DOUBLE data types are used to represent approximate numeric data values."

Geldbeträge willst du nicht "approximativ" angeben, da hätte neben den Kunden des Shopsystems vermutlich auch der Fiskus was dagegen.

Deshalb:
"The DECIMAL and NUMERIC data types are used to store exact numeric data values. [...] These types are used to store values for which it is important to preserve exact precision, for example with monetary data."

MfG ChrisB

[hotti]

hi,

Deshalb:
"The DECIMAL and NUMERIC data types are used to store exact numeric data values. [...] These types are used to store values for which it is important to preserve exact precision, for example with monetary data."

Int ist auch ein numerischer Typ. Und da es offensichtlich keine speziellen Finanzwirtschaftlichen Funktionen gibt, die einen speziellen Feldtyp erfordern, würde ich mich in diesem Fall für int entscheiden und die Beträge in Cent speichern. Präziser gehts nicht.

Hotte

[Tom]

Hello,

Int ist auch ein numerischer Typ. Und da es offensichtlich keine speziellen Finanzwirtschaftlichen Funktionen gibt, die einen speziellen Feldtyp erfordern, würde ich mich in diesem Fall für int entscheiden und die Beträge in Cent speichern. Präziser gehts nicht.

Damit verschenkst Du aber Definitionsraum. Decimal kann wesentlich mehr als der klassische Integer.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[hotti]

Hello,

»» Int ist auch ein numerischer Typ. Und da es offensichtlich keine speziellen Finanzwirtschaftlichen Funktionen gibt, die einen speziellen Feldtyp erfordern, würde ich mich in diesem Fall für int entscheiden und die Beträge in Cent speichern. Präziser gehts nicht.

Damit verschenkst Du aber Definitionsraum. Decimal kann wesentlich mehr als der klassische Integer.

Definitionsraum? Wenn die Kasse auf den Cent genau stimmen soll, rechne ich in Cent.

Hotte

[Vinzenz Mai]

Hallo,

» »» Int ist auch ein numerischer Typ. Und da es offensichtlich keine speziellen Finanzwirtschaftlichen Funktionen gibt, die einen speziellen Feldtyp erfordern, würde ich mich in diesem Fall für int entscheiden und die Beträge in Cent speichern. Präziser gehts nicht.

selbstverständlich geht's präziser :-)

Definitionsraum? Wenn die Kasse auf den Cent genau stimmen soll, rechne ich in Cent.

CURRENCY, DECIMAL, oder was auch immer das DBMS bietet. Ganz gewiß nehme ich *keine* Integer und rechne in Cent. Wozu? Warum sollte ich die Umrechnung in Euro oder Dollar oder was auch immer zweimal selbst erledigen? Komplexerer Code, größere Fehleranfälligkeit.

Es ist eine gute Idee, stets den am besten passenden Datentyp zu wählen, den das DBMS für eine Aufgabe zu bieten hat. Für Geldbeträge ist dies im Fall von MySQL DECIMAL. Jeder andere Datentyp ist schlechter geeignet.

Ja, ich weiß, es gibt auch Helden, die die Uhrzeit als Integer speichern :-(

Freundliche Grüße

Vinzenz

[hotti]

hi,

Warum sollte ich die Umrechnung in Euro oder Dollar oder was auch immer zweimal selbst erledigen? Komplexerer Code, größere Fehleranfälligkeit.

Gestern hab ich gefragt, ob mysql dazu spezielle Funktionen (Rechnungswesen/Finanzen) hat, die Antwort war nein.

Es ist eine gute Idee, stets den am besten passenden Datentyp zu wählen, den das DBMS für eine Aufgabe zu bieten hat. Für Geldbeträge ist dies im Fall von MySQL DECIMAL. Jeder andere Datentyp ist schlechter geeignet.

Ich vermisse immer noch eine genaue Begründung warum das so sein soll. Eine Kasse muss auf dem Cent genau stimmen, da wird nicht in "Euro Komma irgendwas" gerechnet, sondern in Cent.

Ja, ich weiß, es gibt auch Helden, die die Uhrzeit als Integer speichern :-(

Siehst Du, lieber Vinzent, damit ist es ganz ähnlich: Wenn MySQL KEINE Funktionen bietet, wo mir ein spezieller Feldtyp Vorteile bietet, entscheide ich mich für einen Feldtyp der möglichst nahe an der Praxis ist.

Warum sollte ich einen Feldty "Date/Time" benutzen, wo mir die Funktionen, die MySQL dazu bietet, nichts, aber auch absolut gar nichts nützen!?

Schau Dir mal meine
Kalenderberechnungen an. Die Mondphasen kommen aus einer MySQL-Tabelle. Die praxisnahe Erfordernis der Genauigkeit ist "Tageweise". Das ist auch im Script die kleinste Berechnungseinheit, es wird "Auf den Tag genau gerechnet".

Viele Grüße,
Hotte

[dedlfix]

echo $begrüßung;

» Es ist eine gute Idee, stets den am besten passenden Datentyp zu wählen, den das DBMS für eine Aufgabe zu bieten hat. Für Geldbeträge ist dies im Fall von MySQL DECIMAL. Jeder andere Datentyp ist schlechter geeignet.
Ich vermisse immer noch eine genaue Begründung warum das so sein soll. Eine Kasse muss auf dem Cent genau stimmen, da wird nicht in "Euro Komma irgendwas" gerechnet, sondern in Cent.

Es gibt Leistungen, die werden in Bruchteilen von Cents abgerechnet. Wenn du dein System auf Cent-Berechnung eingestellt hast, bekommst du nun ein Problem. Du könntest jetzt mit Aufwand dein System auf Zehntel-Cent-Rechnung umstellen und bekommst das nächste, wenn der Chef sagt: "0,15 Cent soll es nun kosten". Dabei geht dir jedes Mal "am linken Rand" die höchstwertige Stelle verloren, was sich vielleicht nicht bei den kleinen Preisen aber bei der Summierung größerer Posten davon bemerkbar macht. Bei DECIMAL gehst du nur mit der Präzision von (10,2) auf (11,3) oder (12,4).

Siehst Du, lieber Vinzent, damit ist es ganz ähnlich: Wenn MySQL KEINE Funktionen bietet, wo mir ein spezieller Feldtyp Vorteile bietet, entscheide ich mich für einen Feldtyp der möglichst nahe an der Praxis ist.

In Cent zu rechnen soll praxisnäher sein als in Euro und Cent? Es hat sich ja nicht umsonst jemand den Typ DECIMAL ausgedacht. Die Probleme, die du momentan nicht erkennst, sind damit schon gelöst.

echo "$verabschiedung $name";

[hotti]

hallo echo,

Es gibt Leistungen, die werden in Bruchteilen von Cents abgerechnet. Wenn du dein System auf Cent-Berechnung eingestellt hast, bekommst du nun ein Problem. Du könntest jetzt mit Aufwand dein System auf Zehntel-Cent-Rechnung umstellen und bekommst das nächste, wenn der Chef sagt: "0,15 Cent soll es nun kosten". Dabei geht dir jedes Mal "am linken Rand" die höchstwertige Stelle verloren, was sich vielleicht nicht bei den kleinen Preisen aber bei der Summierung größerer Posten davon bemerkbar macht. Bei DECIMAL gehst du nur mit der Präzision von (10,2) auf (11,3) oder (12,4).

Donnerwetter, das leuchtet sogar mir Holzkopf ein, Danke Dir!!!

»» Siehst Du, lieber Vinzent,

Sorry Vinzenz, hatte Deinen Namen falsch geschrieben.

Viele Grüße,
Horst Holzbacke

[ChrisB]

Hi,

Wenn die Kasse auf den Cent genau stimmen soll, rechne ich in Cent.

Ich in Euro - mit zwei Nachkommastellen.

MfG ChrisB