Verhalten von FLOAT

[Martin Tröger]

Hallo Wolfgang,

"Wolfgang Hauck" <wbh@euta.net> schrieb:

>Bei der Überführung von Datenbanken MSSQL <-> mySQL bzw. Access <->
mySQL
>kam es in allen Fällen selbst bei gleicher Deklaration von FLOAT bzw.
>DECIMAL ab der fünften Stelle zu Rundungsfehlern. Die einzige
Möglichkeit
>die Daten ohne Rundungsfehler zu überführen bestand darin alle FLOAT
bzw.
>DECIMAL - Werte als Text zu exportieren und anschliessend in der
Export -
>Datenbank die Umwandlung des Feldes in FLOAT bzw. DECIMAL vorzunehmen.
>Wie's bei Oracel ist weiss ich nicht. Die Rundungsfehler kommen nur bei
>einigen wenigen Daten vor, können aber wenns um Genauigkeit geht sehr
>störend sein, zumal man es bei grossen Datenmengen erst später bemerkt
:/

Das wäre natürlich eine Möglichkeit. Aber rein aus Interesse (und einer
mir abverlangten Studienarbeit ;-)) würde ich das weitestgehend
automatisieren wollen. Meine bisherigen Erkenntnisse habe ich eben als
Antwort auf Ralfs Posting geschrieben. Leider bleibt es nicht nur dabei.
In Oracle kann problemlos ein Foreign Key mit Datentyp NUMBER(p) (was in
Oracle als Integer interpretiert wird) eine Spalte mit Datentyp
NUMBER(p,s) - also eine Fließkommazahl - referenzieren. Was eigentlich
auch korrekt ist, soweit der Wertebereich von NUMBER(p) nicht den der
Vorkommastellen von NUMBER(p,s) übersteigt. Überführe ich jetzt im Zuge
einer optimalen, speicherbedarfsminimierenden (puhhh...) Konvertierung
NUMBER(p) in INT(M) und NUMBER(p,s) in FLOAT, DOUBLE oder DECIMAL, stehe
ich in MySQL vor einem Problem, will ich die Foreign Keys übernehmen.
Denn die dürfen nur auf 'kompatible' Datentypen referenzieren. Aber das
nur am Rande, dass die Analyse einer solchen Migration sehr aufwendig
werden wird {:-).

Gruß, Martin



-- 
Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter
-->>  http://www.4t2.com/mysql