![]() Mailinglisten-Archive |
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
php::bar PHP Wiki - Listenarchive