MySQL: 3.0 als Zahl speichern

[Scream]

Welcher Datentyp muss ich wählen, damit ich 3.0 als Zahl in die DB ablegen kann?
Leider schneidet er mir die 0 immer weg. Ich bräuchte sie aber in der DB.

[Gast]

http://dev.mysql.com/doc/refman/5.0/en/numeric-types.html

FLOAT oder DOUBLE

[Scream]

ne bei beiden macht der aus 3.0 automatisch wieder 3

[][immy]

ne bei beiden macht der aus 3.0 automatisch wieder 3

darf ich fragen, wieso du eine .0 brauchst?
float und double speichern die nachkommastellen, nur lohnt sich das halt bei einem .0 nicht.

sonst würde sich noch nen varchar anbieten, aber dafür isses dann text.

[Berni]

Die Nachkommastelle ist ja da nur wird sie halt in der Darstellung weggerundet. Ansonsten nimm DECIMAL: http://dev.mysql.com/doc/refman/5.1/en/precision-math-decimal-changes.html

[Scream]

[immy;6837686']darf ich fragen, wieso du eine .0 brauchst?
float und double speichern die nachkommastellen, nur lohnt sich das halt bei einem .0 nicht.

sonst würde sich noch nen varchar anbieten, aber dafür isses dann text.

nicht wirklich wichtig ;)
ich bastle ne kleine versionsverwaltung und dachte dass ich dann als erste version z.b. 3.0 abspeichern könnte

find ich eben schöner als nur 3, aber wirklich wichtig ist es nicht, sonst könnt ichs auch per php dazubasteln

[Monger]

Eine Versionsbezeichnung ist keine Zahl!
Sondern Typenmäßig ein String.

Je nach Vereinbarung können Versionsnummern z.B. auch so aussehen:

V1.1.3821a

Das ist ein ganz eigenes Format, was sich dann mit Float/Double einfach nicht mehr vernünftig abbilden lässt. Für sowas musst du schon einen String verwenden.
Wenn du allerdings eine Versionsverwaltung baust, bietet sich ohnehin ein Wert an der auch zählbar ist, also ein Integer, ohne Punkt und Komma.

[Gnafoo]

Oder mehrere Felder: Major, Minor, Revision, was du brauchst. Das nachher als V. x.y.z darzustellen ist ein Darstellungsproblem und hat mit der Speicherung in der Datenbank erstmal nichts zu tun.

[Scream]

@Monger
ist zwar nur ne kleine versionsverwaltung für artikel meines CMS aber du hast mich überzeugt^^
daher werde ich das Feld als VARCHAR anlegen

[PatkIllA]

@Monger
ist zwar nur ne kleine versionsverwaltung für artikel meines CMS aber du hast mich überzeugt^^
daher werde ich das Feld als VARCHAR anlegen
Und da reicht nicht einfach ein Integer? Kann man auch viel besser sortieren

[Scream]

eigentlich schon aber ich finds schöner wenn man Version 3.0, 3.01 oder 3.1 hat

[ScottManDeath]

Was spricht dagegen 300 abzuspeichern mit der Konvention das die letzten 2 Dezimalstellen nach dem Komma stehen?

[Gast]

ne bei beiden macht der aus 3.0 automatisch wieder 3

Formatierung ist auch nicht die Angelegenheit der DB, sondern deiner Anwendung. Es stellt ja wohl kein Problem dar, dass deine Anwendung aus der 3 eine 3,0 macht.

[Berni]

Ich verstehe auch nicht was gegen meinen Vorschlag von DECIMAL spricht...der Gast hat aber auch recht denn float oder double kann man mit jeder Programmiersprache (insbesondere php um was es wohl gehen wird?) wunderbar formatieren so dass auch die 0 da ist.

[Scream]

klar sind all eure lösungen kein problem

Der Hauptgrund warum ich die Frage gestellt habe war reines Interesse ob das mit der .0 abspeichern möglich wäre.
Wenn ja hätte ich das eben genommen weil ich mir dann die Formatierung schenken könnte.

Die eine Zeile Code ist ja kein Problem ;)

[Berni]

Der Hauptgrund warum ich die Frage gestellt habe war reines Interesse ob das mit der .0 abspeichern möglich wäre.
Gibt es ja mit DECIMAL. Beispiel:
CREATE TABLE `test` (
`test` decimal(6,1) NOT NULL
)

[Monger]

Vielleicht mal noch ein paar grundsätzliche Sätze dazu...

Für die meisten Menschen ist es nicht ganz einsichtig, was denn der Unterschied zwischen einer Zahl, und der Repräsentation einer Zahl ist. Wenn ich schreibe:

42

so ist das eben keine Zahl, sondern die textuelle Repräsentation einer Zahl in unserem Zahlensystem. Ich hätte auch römische Ziffern schreiben können, oder 84/2 - mathematisch gesehen ist das immer noch die selbe Zahl.

Auch eine 3.0 lässt sich eben als 3, 3.00 oder als .30000000 * 10^1 darstellen (wie sie ja dann tatsächlich im Speicher abgelegt wird).

Das mag wie Korinthenkackerei wirken, aber Zahlen sind IMMER interpretationsbedürftig wenn man sie darstellen will. Wenn man sich auf irgendwelche Konventionen verlässt, ist die Chance groß dass man damit früher oder später auf die Nase fliegt, weil Konventionen nunmal äußerst fließend sind. Alleine schon, dass hier für die Komma Stelle ein Komma, und im amerikanischen Raum ein Punkt vorgesehen ist, hat schon so manche Software gecrasht! ;)
Praktisch gesehen heißt das z.B. , dass die Suche nach einer bestimmten Zahl höllisch kompliziert werden kann, wenn man sich mit verschiedenen Formatierungsvarianten rumschlagen muss. Eine Suche nach einem Integer ist verdammt schnell, eine Suche nach dem String "42" kann unglaublich langsam sein. Auf der anderen Seite kommst du in Teufels Küche, wenn du versuchst irgendwas in eine Zahl zu quetschen, was eigentlich keine Zahl ist. Wenn du z.B. versuchst, 3.0 als Float abzulegen, ist es nicht völlig ausgeschlossen dass da je nach Randbedingungen Rundungsfehler auftauchen. Und eine Versionsbezeichnung von 3.00000000001 wäre doch äußerst unschön, oder? ;)

[Krishty]

Dabei handelt es sich bei 3.0 ja nicht einmal um eine Zahl, sondern um zwei. Genau wie die Uhrzeit 23:35 nicht der Zahl 23,35 entspricht. Ohne MySQL zu können halte ich über Implementationsdetails aber lieber die Klappe.

[Berni]

Es wird in einem binären Spezialformat gespeichert wobei die Zahl natürlich getrennt nach Teil vor und nach dem Komma gespeichert ist. Es ist aber relativ speichereffizient so wie ich das sehe und es dürfte auch performant sein. Die Seite zu den Details hatte ich ja schon oben verlinkt.

Values for DECIMAL columns in MySQL 5.1 are stored using a binary format that packs nine decimal digits into four bytes. The storage requirements for the integer and fractional parts of each value are determined separately. Each multiple of nine digits requires four bytes, and any digits left over require some fraction of four bytes. For example, a DECIMAL(18,9) column has nine digits on either side of the decimal point, so the integer part and the fractional part each require four bytes. A DECIMAL(20,10) column has ten digits on either side of the decimal point. Each part requires four bytes for nine of the digits, and one byte for the remaining digit.

The storage required for leftover digits is given by the following table:

Leftover Digits Number of Bytes
0 0
1 1
2 1
3 2
4 2
5 3
6 3
7 4
8 4
9 4