Eurich in Datenbank

[Gabi F.]

Hi,

eine Frage zum Geld in DB.

Einen Geldbetrag (euro.cent) in einer mySQL Datenbank
als decimal(12,2) abzulegen oder
Euro und Cent getrennt in einer Spalte.

Was macht mehr Sinn???

Grüßle

[Doppelposter]

Vergleiche doch mal mit[pref:t=35650&m=194624]

[Frank aus Ulm]

Hi, hallo

was sollte denn der besondere Sinn sein, den Wert in 2 Spalten zu trennen.. du hast mehr arbeit, weil du den Wert immer erst zerlegen mußt und dann wieder zusammensetzen. Außerdem verringert es den Überblick und könnte für spätere Optimierung Probleme verursachen.

und welchen Sinn macht es, die Frage zu wiederholen, vor allem nach so kurzer Zwischenzeit und trotz einiger Antworten beim ersten Posting - und deswegen eins auf den Deckel zu kriegen. :-)

Tschau, tschüß,
Frank

[Gabi F.]

Ich habe bei einigen Formularen (z.B. Advance Bank) gesehen,
dass zum eingeben des Geldbetrages (Euro und Cent) zwei getrennte <INPUT>-Felder benutzt werden. Macht es da nicht Sinn, zwei Spalten anzulegen in der DB?

[Odium]

Hallo,

wie etwas in Input-Feldern steht und wie es dann verarbeitet wird sind zwei getrennte sachen...

ich denke auf diese weise werden sie die überprüfung der eingabe durchführen, ist die überprüfung erfolgreich kann es dann in der db abgelegt werden.

hier steht was zu datentypen:

http://www.mysql.com/documentation/mysql/bychapter/manual_Reference.html

Odium

[Andreas Cloos]

Hallo Zusammen,

Ich habe bei einigen Formularen (z.B. Advance Bank) gesehen,
dass zum eingeben des Geldbetrages (Euro und Cent) zwei getrennte <INPUT>-Felder benutzt werden. Macht es da nicht Sinn, zwei Spalten anzulegen in der DB?

Das würde ich nur machen, um verschiedene Eingabearten abzufangen, zB

für 10 Euro (glatt)
10.00
10,00
10

oder einen Betrag mit Cent:
10.20
10,20

Dann käme aber noch das Problem auf Dich zu, daß ein User noch 1000er-Trennzeichen (Punkt oder Komma) eingeben kann. Also gucken, ob er das gemacht hat, den String am nichtnumerischen Zeichen auseinandernehmen und ohne dieses Zeichen wieder zusammenbauen...

[Lude]

Hi,

Dann käme aber noch das Problem auf Dich zu, daß ein User noch 1000er-Trennzeichen (Punkt oder Komma) eingeben kann. Also gucken, ob er das gemacht hat, den String am nichtnumerischen Zeichen auseinandernehmen und ohne dieses Zeichen wieder zusammenbauen...

Tausendertrennzeichen wurde ich nicht unterstuetzen, weil folgendes Problem auftritt:
("international": 1,000.00 ($)
 "deutsch": 1.000,00 ())
Was macht man dann bei Eingaben wie z.B. '111.000'? - Steht das nun fuer 111$ oder 111000?
(Problem ganz grob skizziert)

Gruss,
Lude

[Michael Schröpl]

Hi Gabi F.,

Ich habe bei einigen Formularen (z.B. Advance Bank) gesehen,
dass zum eingeben des Geldbetrages (Euro und Cent) zwei getrennte <INPUT>-Felder benutzt werden.

das erspart es dem Anwender, zu erraten, ob er den Nachkomma-Anteil mit einem Punkt, einem Komma oder was auch immer abtrennen muß.
Ein Formular, das ihm die Möglichkeit verweigert, etwas falsch machen zu können, ist IMHO durchaus benutzerfreundlich.

Macht es da nicht Sinn, zwei Spalten anzulegen in der DB?

Nein. Interne und externe Repräsentation dienen ganz unterschiedlichen Zwecken.

Viele Grüße
      Michael

[Lude]

Hi,

eine Frage zum Geld in DB.

Einen Geldbetrag (euro.cent) in einer mySQL Datenbank
als decimal(12,2) abzulegen oder
Euro und Cent getrennt in einer Spalte.

Was macht mehr Sinn???

Grüßle

Hi,

das Nutzen von zwei Datenfeldern, wenn eins ausreichen wuerde, ist eine Todsuende. Eins reicht im genannten Fall aus (Die Verwendung eines INT-Datentyps fuer die Cents waere zudem grausig).

Gruss,
Lude

[Michael Schröpl]

Hi Lude,

das Nutzen von zwei Datenfeldern, wenn eins ausreichen wuerde, ist eine Todsuende. Eins reicht im genannten Fall aus (Die Verwendung eines INT-Datentyps fuer die Cents waere zudem grausig).

warum? Es ist die einzige Möglichkeit, Rundungsfehler definitiv auszuschließen. Und nebenbei ist Integer-Arithmetik sogar schnell ...

Viele Grüße
      Michael

[Lude]

Hi, Michael,

das Nutzen von zwei Datenfeldern, wenn eins ausreichen wuerde, ist eine Todsuende. Eins reicht im genannten Fall aus (Die Verwendung eines INT-Datentyps fuer die Cents waere zudem grausig).

warum? Es ist die einzige Möglichkeit, Rundungsfehler definitiv auszuschließen. Und nebenbei ist Integer-Arithmetik sogar schnell ...

ich vermute mal, dass Du Dich auf den zweiten Satz meines Postings bezogen hast:
1.) Ich plaediere (entschieden) fuer das Nutzen des Datentyps NUMERIC(18,2) fuer Geldbetraege.
2.) Bei der Verwendung des Datentypes INT wird (zwangslaeufig) (nach Murphy) das Datenfeld "Cent" in einigen Datensaetzen einen Wert >= 100 annehmen.
3.) "Rundungsfehler" sind normal, dass heisst es muss bei finanzmathematischen Berechnungen ggf. gerundet werden. Oder hab' ich da was missverstanden?
4.) Performanceueberlegungen spielen beim DB-Design (erst einmal) keine Rolle. Man bildet einen zu unterstuetzenden Vorgang der "Realitaet" bestmoeglich ab.
5.) Performanceueberlegungen in diesem konkreten Fall fuehren (eindeutig) zu keinem Handlungsbedarf.

Morgendliche Gruesse,
Lude

[Michael Schröpl]

Hi Lude,

2.) Bei der Verwendung des Datentypes INT wird (zwangslaeufig) (nach Murphy) das Datenfeld "Cent" in einigen Datensaetzen einen Wert >= 100 annehmen.

ich habe niemals empfohlen, zwei Felder nehmen.

3.) "Rundungsfehler" sind normal, dass heisst es muss bei finanzmathematischen Berechnungen ggf. gerundet werden. Oder hab' ich da was missverstanden?

Aber _wie_ gerundet werden muß, entscheidet der Gesetzgeber - nicht die Datenbank-Implementierung.

4.) Performanceueberlegungen spielen beim DB-Design (erst einmal) keine Rolle. Man bildet einen zu unterstuetzenden Vorgang der "Realitaet" bestmoeglich ab.

Eben. Und die Realität ist, daß Geld in Integer existiert und nicht in Float.

Viele Grüße
      Michael

[Lude]

Hi, Michael,

2.) Bei der Verwendung des Datentypes INT wird (zwangslaeufig) (nach Murphy) das Datenfeld "Cent" in einigen Datensaetzen einen Wert >= 100 annehmen.

ich habe niemals empfohlen, zwei Felder nehmen.

Deine in ANLAGE1 zitierte Aussage war missverstaendlich.

3.) "Rundungsfehler" sind normal, dass heisst es muss bei finanzmathematischen Berechnungen ggf. gerundet werden. Oder hab' ich da was missverstanden?

Aber _wie_ gerundet werden muß, entscheidet der Gesetzgeber - nicht die Datenbank-Implementierung.

Das _wie_ entscheidet die DB-Implementierung; der Gesetzgeber prueft. (Klingt etwas zynisch, aber harte Realitaet bei den Finanzdienstleistern :-)

4.) Performanceueberlegungen spielen beim DB-Design (erst einmal) keine Rolle. Man bildet einen zu unterstuetzenden Vorgang der "Realitaet" bestmoeglich ab.

Eben. Und die Realität ist, daß Geld in Integer existiert und nicht in Float.

Genau. Ist NUMERIC aber INT? Und wenn Du einen INT-Typ verwendest brauchst Du zwei DFs. (Aussagen beziehen sich auf DB(M)Systeme)

Gruss,
Lude

ANLAGE1:

(Lude)

das Nutzen von zwei Datenfeldern, wenn eins ausreichen wuerde, ist eine Todsuende. Eins reicht im genannten Fall aus (Die Verwendung eines INT-Datentyps fuer die Cents waere zudem grausig).

(MS)

warum? Es ist die einzige Möglichkeit, Rundungsfehler definitiv auszuschließen. Und nebenbei ist Integer-Arithmetik sogar schnell ...

[Michael Schröpl]

Hi Lude,

Und wenn Du einen INT-Typ verwendest brauchst Du zwei DFs.

keineswegs. Ich brauche lediglich eine Division durch 100 für bestimmte Ausgabezwecke.

Viele Grüße
      Michael

[Lude]

Hi, Michael,

Und wenn Du einen INT-Typ verwendest brauchst Du zwei DFs.

keineswegs. Ich brauche lediglich eine Division durch 100 für bestimmte Ausgabezwecke.

jetzt hab' ich Dich verstanden (Licht geht auf). - Du willst Geldbetraege in Pfennigen oder Equivalentem speichern und Du meinst, dass das eine gute Loesung ist. - Wird das irgendwo gemacht? Welchen INT-Typ empfiehlst Du?

(Bei uns wurde mal bis zum geht nicht mehr diskutiert, ob man den T-SQL Datentyp 'money' verwenden sollte; sollte man nicht.)

Verzeihe mir, dass ich bei meinem Lieblingsthema etwas hartnaeckig bin.

Gruss,
Lude

[Michael Schröpl]

Hi Lude,

Und wenn Du einen INT-Typ verwendest brauchst Du zwei DFs.
keineswegs. Ich brauche lediglich eine Division durch 100 für bestimmte Ausgabezwecke.
jetzt hab' ich Dich verstanden (Licht geht auf). - Du willst Geldbetraege in Pfennigen oder Equivalentem speichern und Du meinst, dass das eine gute Loesung ist.

ja und ja.

Wird das irgendwo gemacht?

Ich würde es nie anders machen ... reicht Dir das? ;-)

Welchen INT-Typ empfiehlst Du?

Denjenigen, der Deine Aufgabenstellung erfüllt ... wie große Beträge mußt Du darstellen können?

Viele Grüße
      Michael

[Lude]

Hi, Michael,

Welchen INT-Typ empfiehlst Du?

Denjenigen, der Deine Aufgabenstellung erfüllt ... wie große Beträge mußt Du darstellen können?

TSQL von Microsoft SQL Server unterstuetzt seit Version 7 (?) anscheinend auch den Datentyp 'bigint' mit dem zulaessigen Wertebereich
-2^63 (-9223372036854775808) bis 2^63-1 (9223372036854775807), "klassisches" 'int'(4Byte) wuerde "uns" nicht ausreichen.

---

Irgendwie habe ich aber dennoch den Eindruck, dass ein realer Sachverhalt (Waehrung und "Subwaehrung") durch Verwendung eines einzigen Datenfeldes der Typklasse 'int' schlechter abgebildet wird, als durch die Verwendung von 'numeric(x,y)'.

---

Stell' Dir mal vor, dass die Eurocents abgeschafft (oder Vergleichbares in Fremdwaehrungen, die wir auch "halten") werden. - Was macht man denn dann? - Einen "Lauf" ueber alle Datenbestaende? - Der "Director IT" wird den Galgen dann genuesslich richten - oder die Sache wird vertuscht und kommt 20 Jahre spaeter 'raus.
---

Ich vermute mal, dass Du Deine Postspiele "waehrungstechnisch" auf 'int' abgerichtet hast. - btw - Ich habe frueher mal kurzzeitig Fernschach gespielt, weil ich keine Gegner am Ort hatte; war aber doch sehr gewoehungsbeduerftig.

Gruss,
Lude

[Michael Schröpl]

Hi Lude,

Stell' Dir mal vor, dass die Eurocents abgeschafft (oder Vergleichbares in Fremdwaehrungen, die wir auch "halten") werden. - Was macht man denn dann?

nichts - wieso sollte ich etwas tun müssen?

Ein Problem wäre es nur, wenn Zehntel-Cents eingeführt werden würden - das würde mein Datenmodell ändern.

Ich vermute mal, dass Du Deine Postspiele "waehrungstechnisch" auf 'int' abgerichtet hast.

http://www.schroepl.net/pbm/partien/yield/_1911_h/boerse.htm
(Und ja, das sind intern Integers für die Hundertstel-Kujambel.)

Viele Grüße
      Michael

[Thomas Schmieder]

Hallo Gabi,

das scheint Dich ja echt zu belasten. Ich habe mir die ganzen Argumente nochmal durchgelesen und unser kleiner Test im anderen Thread hat Dir ja auch gezeigt, wie höllisch man da wegen der Formatierung aufpassen muss. Michael Schröpl hat wohl das wichtigste Argument gebracht: Verantwortlich bist DU alleine und nicht das DBMS.

Da würde ich mir das Leben jetzt nicht so schwer machen und einfach mal den Datenkreislauf mit Bleistift und Radiergummi aufs Papier bringen. Und dann wirst Du feststellen, dass es am bequemsten für Dich UND die Kunden sein wird, zwei Erfassungsfelder zu nehmen und die dann NACH aufwändiger Prüfung in einem Decimal zusammenzufassen. Wie willst Du denn sonst am Client dafür sorgen, dass für Vor- und Nachkommastellen nur eine bestimmte Anzahl Zeichen eingegeben werden soll. Das muss man zwar beim Server auf jeden fall prüfen, aber eine kleine Eingabehilfe kannst Du dem Normalbenutzer damit auch geben.

Liebe Grüße aus http://www.braunschweig.de

Tom