Preise im Format "1.234,90" addieren

[Paul]

Ich habe in einer Mysql-db preise in oben angeführter formatierung. die formatierung wurde immer strikt eingehalten.

wie kann ich solche werte addieren? muss ich eine funktion basteln, die den beistrich durch punkt ersetzt und den/die punkte rauslöscht?

oder soll ich mich mit den numeric types in mysql beschäftigen (kenn ich nur vom hörensagen...)?

oder ganz anders??

bin gespannt auf eure expertenmeinung!

p

[Baer]

Ich habe in einer Mysql-db preise in oben angeführter formatierung. die formatierung wurde immer strikt eingehalten.

wie kann ich solche werte addieren? muss ich eine funktion basteln, die den beistrich durch punkt ersetzt und den/die punkte rauslöscht?

oder soll ich mich mit den numeric types in mysql beschäftigen (kenn ich nur vom hörensagen...)?

oder ganz anders??

bin gespannt auf eure expertenmeinung!

<code>
<?php
  $var_1 = '1.234,56';
  $var_multipiziere = 2;

$my_real = (float) str_replace(',',  '.', str_replace('.', '', $var_1));
  $my_real = $my_real * $var_multipiziere;
  echo "engl.: $my_real \n";
  echo "deutsch: "  .  number_format($my_real,2,',','.')  . "\n";
?>
</code>

[ChrisB]

Hi,

oder soll ich mich mit den numeric types in mysql beschäftigen (kenn ich nur vom hörensagen...)?

Ja. Daten solltest du *immer* in einem passenden Feldtyp vorhalten.
Formatierung für den menschlichen Betrachter erfolgt immer erst bei der Ausgabe.

MfG ChrisB

[Paul]

hi,

Ja. Daten solltest du *immer* in einem passenden Feldtyp vorhalten.
Formatierung für den menschlichen Betrachter erfolgt immer erst bei der Ausgabe.

ich habe aber die daten nun mal so zur verfügung. dh. also, dass ich die punkt- und beistrich-formatierung vorher rauslöschen muss, dann als integer abspeichern, und die formatierung nachher wieder dazufügen?

[EKKi]

Mahlzeit Paul,

ich habe aber die daten nun mal so zur verfügung.

Das mag sein. Es mag auch sein, dass Du irgendeine Frickellösung hinbekommst, die an genau dieser einen Stelle einmalig funzt™ und Dein Problem scheinbar löst. Trotzdem solltest Du Dir darüber im Klaren sein, dass Dein Datenbankdesign defekt ist und Du sinnvollerweise die *Ursache* (in diesem Fall den falschen Feld- bzw. Spaltentyp) beheben solltest.

dh. also, dass ich die punkt- und beistrich-formatierung vorher rauslöschen muss,

Vorher? Vor was? Vor der Änderung des Feldtyps? Ja.

dann als integer abspeichern,

Nein. Das wurde Dir doch in mehreren Beiträgen erläutert. Bei MySQL könnte z.B. der Spaltentyp DECIMAL sinnvoll sein.

und die formatierung nachher wieder dazufügen?

Nachher? Nach was? Nach dem Auslesen der Werte - bzw. vor der Ausgabe in dem von Dir verwendeten Kontext (vermutlich HTML)? Ja.

MfG,
EKKi

[Baer]

Ich habe in einer Mysql-db preise in oben angeführter formatierung. die formatierung wurde immer strikt eingehalten.

wie kann ich solche werte addieren? muss ich eine funktion basteln, die den beistrich durch punkt ersetzt und den/die punkte rauslöscht?

oder soll ich mich mit den numeric types in mysql beschäftigen (kenn ich nur vom hörensagen...)?

oder ganz anders??

bin gespannt auf eure expertenmeinung!

Wenn du nachhaltig Arbeiten willst, würde ich den Tip von ChrisB
fogen. Wenn du einfach nur fertig werden willst, dann folge meinen
Tip. Thats life ....

[Gunnar Bittersmann]

@@Paul:

nuqneH

Ich habe in einer Mysql-db preise in oben angeführter formatierung. die formatierung wurde immer strikt eingehalten.

Das heißt, du speicherst Strings statt numerischer Werte in der DB?

oder soll ich mich mit den numeric types in mysql beschäftigen (kenn ich nur vom hörensagen...)?

Ja.

„Kapitel 11 - die ersten 10 können wir vergessen.“ (Keimzeit)

Qapla'

[EisFuX]

(Hallo|Hi(ho)|Mahlzeit) Paul,

Ich habe in einer Mysql-db preise in oben angeführter formatierung. die formatierung wurde immer strikt eingehalten.

Also benutzt du Zeichenketten (Strings)?
Mensch, es geht um Kohle!!!111 Da kommt es doch auf jeden Cent an.
Stell dir vor, dein Gehalt | Einkommen würde so verwaltet ... ;-)

Eine ordentliche Datenbank hat für diesen Zweck einen passenden (numerischen) Datentyp wie
CURRENCY oder MONEY. FIXED, NUMERIC oder DECIMAL tuns aber auch.
Wenn nicht, würde ich auf Ganzzahlen (INTEGER) zurückgreifen, aber die Beträge in der kleinsten verfügbaren Einheit abspeichern.
Beim Euro wären das Cents, wenn zwischen verschiedenen Währungen umgerechnet wird, können das aber auch Bruchteile davon sein.

bin gespannt auf eure expertenmeinung!

Wenns um die eigene Kohle geht, sollten wir alle Experten sein. :-P

MffG
EisFuX

[Gunnar Bittersmann]

@@EisFuX:

nuqneH

Wenn nicht, würde ich auf Ganzzahlen (INTEGER) zurückgreifen, aber die Beträge in der kleinsten verfügbaren Einheit abspeichern.
Beim Euro wären das Cents

Nicht an der Tankstelle.

Qapla'

[EisFuX]

(Hallo|Hi(ho)|Tag) Gunnar Bittersmann,

Wenn nicht, würde ich auf Ganzzahlen (INTEGER) zurückgreifen, aber die Beträge in der kleinsten verfügbaren Einheit abspeichern.
Beim Euro wären das Cents

Wusst ich's doch, dass ich wieder einen Sonderfall vergessen hatte ...
Wobei zumindest in Österreich die Bruchteile-von-Cent-Regelung auf die Währungsumstellung
von Schilling nach Euro zurückzuführen sein soll -- und das hatte ich ja erwähnt.

Nicht an der Tankstelle.

Ich tanke immer ganze Dekaliter. Falls das mal nicht klappt, bestehe ich, als Nichtkaufmann,
selbstverständlich auf Herausgabe der exakten Wechselgeldsumme. ;-)

MffG
EisFuX

[Der Martin]

Hallo,

die Beträge in der kleinsten verfügbaren Einheit abspeichern.
Beim Euro wären das Cents
Nicht an der Tankstelle.

stimmt. Ich frage mich, wann sie mit dem Blödsinn endlich mal aufhören - zumal man auf der letzten Stelle eh selten etwas anderes sieht als die Ziffer 9. Wäre IMHO echt ein Fortschritt, wenn man bei irgendeiner Preiserhöhung zwischendurch mal nicht um 1ct, sondern um 1.1ct erhöhen würde und die Zehntel damit faktisch abschafft.

Obwohl ... Es gibt eine freie Tankstelle hier in der Stadt, die sich anscheinend das Ziel gesetzt hat, die anderen immer um einen halben Cent zu unterbieten. Da stehen dann meistens Preise dran, die mit einer 4 enden.

Ciao,
 Martin

[Klawischnigg]

Hi there,

Ich habe in einer Mysql-db preise in oben angeführter formatierung. die formatierung wurde immer strikt eingehalten.

Wie ja schon erwähnt hat eine Formatierung in Daten, mit denen uU gerechnet werden muss, nichts verloren. Auch wenn Gunnar zurecht einwendet, daß gelegentlich auch Bruchteile von Cents vorkommen können, reichts es idR aus, Geldbeträge als Integer, die Cents repräsentieren, abzuspeichern.

Die Formatierung, die Du ja  nur bei der Darstellung der Beträge benötigst, übernimmt dann einfach eine entsprechende Funktion...

[suit]

reichts es idR aus, Geldbeträge als Integer, die Cents repräsentieren, abzuspeichern.

Wenn man es schon "ungünstig" macht: Warum nicht Dezimal mit zwei Nachkommastellen? :p

[Der Martin]

Hallo,

reichts es idR aus, Geldbeträge als Integer, die Cents repräsentieren, abzuspeichern.
Wenn man es schon "ungünstig" macht: Warum nicht Dezimal mit zwei Nachkommastellen? :p

weil Integer-Rechnungen prinzipbedingt exakt sind (zumindest Addition, Subtraktion und Multiplikation), während beim Rechnen mit IEEE-Floating-Point schnell Rundungsfehler auftreten. Denn viele Zahlenwerte, etwa 4.01 lassen sich in IEEE-Floating-Point gar nicht exakt darstellen, also muss bereits bei der Eingabe bzw. der Speicherung des Werts gerundet werden. Dieser winzige Fehler pflanzt sich bei Rechnungen fort und wächst an. Schließlich kommt man auf einen Rechnungs-Endbetrag von 788.3700271EUR, obwohl alle Teilbeträge in ganzen Cents erfasst wurden.

Ciao,
 Martin

[Gunnar Bittersmann]

@@Der Martin:

nuqneH

Wenn man es schon "ungünstig" macht: Warum nicht Dezimal mit zwei Nachkommastellen? :p

weil Integer-Rechnungen prinzipbedingt exakt sind (zumindest Addition, Subtraktion und Multiplikation), während beim Rechnen mit IEEE-Floating-Point schnell Rundungsfehler auftreten.

Bist du sicher, dass bei DECIMAL mit Fließkomma-Arithmetik gerechnet wird?

Qapla'

[Der Martin]

Hallo,

weil Integer-Rechnungen prinzipbedingt exakt sind (zumindest Addition, Subtraktion und Multiplikation), während beim Rechnen mit IEEE-Floating-Point schnell Rundungsfehler auftreten.
Bist du sicher, dass bei DECIMAL mit Fließkomma-Arithmetik gerechnet wird?

nein - aber da das Thema "PHP" ist, bin ich selbstverständlich von der Datenhaltung und Arithmetik in PHP ausgegangen.
Was kann ich dafür, wenn der OP eine Datenbankfrage irreführenderweise im Bereich PHP stellt, und keiner die Kategorie korrigiert ...

Ciao,
 Martin

[suit]

Was kann ich dafür, wenn der OP eine Datenbankfrage irreführenderweise im Bereich PHP stellt, und keiner die Kategorie korrigiert ...

Ich sehe grade den ersten Stein fliegen. Jehovah!

[EKKi]

Mahlzeit Der Martin,

Was kann ich dafür, wenn der OP eine Datenbankfrage irreführenderweise im Bereich PHP stellt, und keiner die Kategorie korrigiert ...

Lüger!

;-)

MfG,
EKKi

[Der Martin]

Hallo,

Was kann ich dafür, wenn der OP eine Datenbankfrage irreführenderweise im Bereich PHP stellt, und keiner die Kategorie korrigiert ...
Lüger!

sorry, dann nehme ich diese pauschale Anschuldigung hiermit zurück. ;-)
Schade nur, dass dein Versuch so spät im Threadbaum erfolgte und nicht mehr Nachahmer fand. Kam kaum zur Geltung ...

Ciao,
 Martin

[Klawischnigg]

Hi there,

reichts es idR aus, Geldbeträge als Integer, die Cents repräsentieren, abzuspeichern.

Wenn man es schon "ungünstig" macht: Warum nicht Dezimal mit zwei Nachkommastellen? :p

Geht natürlich auch, aber im allgemeinen macht man mit Geld Rechenoperationen, die durch Integerzahlen besser abgebildet werden, ausserdem kommt Geld eben "gequantelt" vor und nicht in beliebigen Bruchteilen... (auch wenn das die Tankstellenheinzis vom lieben Gunnar anders sehen mögen...;)

[Gunnar Bittersmann]

@@Klawischnigg:

nuqneH

Geht natürlich auch, aber im allgemeinen macht man mit Geld Rechenoperationen, die durch Integerzahlen besser abgebildet werden,

Nicht wirklich. Ich denke bei 9876,50 DM [Otto-Film] nicht an 987650 Pfennige.

ausserdem kommt Geld eben "gequantelt" vor und nicht in beliebigen Bruchteilen...

Das ist bei DECIMAL auch der Fall: "gequantelt", nicht in beliebigen Bruchteilen.

Qapla'

[Klawischnigg]

Hi there,

Nicht wirklich. Ich denke bei 9876,50 DM [Otto-Film] nicht an 987650 Pfennige.

Ich denke beim Tippen dieses Textes auch nicht an Bits und Bytes, auch wenn mein Geschreibsel vom Rechner als solche verarbeitet werden.

ausserdem kommt Geld eben "gequantelt" vor und nicht in beliebigen Bruchteilen...

Das ist bei DECIMAL auch der Fall: "gequantelt", nicht in beliebigen Bruchteilen.

nicht beliebig, ok, aber es gibt eben eine eindeutige Grenze, die imho durch einen Integerwert besser dargestellt wird...

[Gunnar Bittersmann]

@@Klawischnigg:

nuqneH

Nicht wirklich. Ich denke bei 9876,50 DM [Otto-Film] nicht an 987650 Pfennige.

Ich denke beim Tippen dieses Textes auch nicht an Bits und Bytes, auch wenn mein Geschreibsel vom Rechner als solche verarbeitet werden.

Ja, eben. Du denkst an einen Datentypen Text, nicht an einen Datentypen Bytes.

Analog: Datentyp Festkommazahl, nicht Integer, auch wenn Festkommazahlen vom Rechner mit Integer-Arithmetik verarbeitet werden (wie ich annehme).

Qapla'