GlobalType™

[Lars Kähler]

Ja, da sind wir gerade dabei. Es gibt aber noch Schwierigkeiten. Von Sequel Pro bin ich jetzt auf Anraten meines Hamburger Freundes und auch meines Stiefbruders, der für mich das erste erweiterte ERM entwickelt hat, zu MySQL Workbench desertiert. Hat diesbezüglich jemand hier Einwände? Plattform ist zunächst mein Mac hier mit OS X 10.7.5 und später der Server, mit einem Linux, den Namen der Distribution weiß ich jedoch nicht selbst.

Das echte Problem ist aber nun, dass es beim Transfer schon etwa die Hälfte der Datensätze verloren gegangen ist, von erwartungsgemäß 91.076 Schriftarten sind ≈ 31.000 übrig geblieben.

Es leuchtet mir ein, dass jetzt zunächst einmal alle Daten übertragen sein müssen, bevor ich damit anfange den Inhalt auf die einzelnen Entitäten zu zerteilen und diese dann einander zugeordnet. Mein ehemaliger Programmier hat mir gesagt, dass die DB mit dem ERM, was ich hier hochgeladen habe, bereits normalisiert sein. Aber in der Tat haben wir noch sehr viele Redundanzen drin, vor allem Schriftschöpfer und Schriftgießereien und Foundries. Die sind aber wenigstens auf verschiedene Schreibweisen durchgekämmt.

 

[akretschmer]

Das echte Problem ist aber nun, dass es beim Transfer schon etwa die Hälfte der Datensätze verloren gegangen ist, von erwartungsgemäß 91.076 Schriftarten sind ≈ 31.000 übrig geblieben.

Die Daten, die Du hier reingestellt hattest, enthielten 31380 Rows.

 

[ukulele]

Von MySQL Workbench habe ich zumindest schonmal gehört, so gesehen ist es denke ich kein Problem. akretschmers Einwand ist berechtigt. Meist läßt sich alles Importieren oder nichts (weil Spaltentrennung oder sonstwas Probleme macht). Fehlen einzelne Datensätze kanns an Sonderzeichen liegen (z.B. Spaltentrenner als Spalteninhalt) oder an so banalen Dingen wie Datei unvollständig.

 

[Lars Kähler]

Ich habe ohnehin den Eindruck, die falsche Datei importieren zu wollen. Es ist jetzt Jahre her, dass ich die Quelldatei – da sie ja nur aus einer einzigen Tabelle bestand –, in Excel bearbeitet und umgestellt habe. Genauergesagt hatte ich eine FileMaker-DB in MySQL importiert, von dort aus in Excel integriert und mit einer PDF-Liste »Mac PostScript-Schriften« zusammengeführt. Händisch. Sollte mich wundern, wenn es da großartig etwas zu skripten oder automatisieren gegeben hätte.

Nach der Rechnung zu schließen, hat der bisherige Programmierer eine »Datenbanknormalisierung (Konzept, Diagramm, und leeres Database Dump) geliefert, wie er selbst noch schrieb. Leider haben wir uns nämlich über die Finanzen zerstritten, oder anders ausgedrückt war der Etat aufgebraucht.

Das hier ist bei mir zu sehen, wenn ich das Dump einmal öffne:

 

[Lars Kähler]

Das sieht ja schon mal gut aus. Scheinbar ist die Struktur jetzt drin, es fehlen die Daten, richtig?

 

[ukulele]

Da sind auf jedenfall Tabellen ja^^

So wie ich das verstehe sind das aber die neuen Tabellen in die später alle Daten rein sollen. Ist die bestehende Tabelle mit den 31k Zeilen jetzt auch schon vollständig importiert?

 

[Lars Kähler]

Danke für die schnelle Antwort. Im Augenblick ist es wirklich spannend für mich, und ich möchte bei der Gelegenheit auch äußern, dass ich mich an anderer Stelle selbstverständlich auch unterstützend zeige.

Ja, diese Tabellen sollen ihre Inhalte aus der Quelldatei bekommen, von der jetzt bisher nur etwa die Hälfte rübergekommen ist. Das war auch nicht meine Leistung, sondern die des Hamburger Freundes, aber wir konnten den Vorgang hier auf meinem Mac trotz gleicher Programmversionen von MySQL und MySQL Workbench, jedoch behindert durch TeamViewer, nicht nachvollziehen.

Frage an Euch alle: Ist es nicht auch von Vornherein besser, die Datenbank gleich direkt auf den späteren Server zu legen? Ich könnte ja die Seiten, die nur zum Testen gedacht sind, erst einmal ausblenden.

 

[ukulele]

Natürlich kann man direkt online mit einer Testseite und der richtigen DB arbeiten, das spart nachher die ganze Arbeit beim Migrieren. Auf die DB sollte aber nur die Seite Zugriff haben und der Zugriff von Außerhalb auf die DB sollte gesperrt oder über VPN / Ähnliches abgesichert werden.

Das ändert aber nichts an der Tatsache das man eine Datei die grade mal 8 Spalten und ~31.000 Zeilen hat (Spaltenüberschriften wären übrigens hilfreich) problemlos in MySQL importieren können sollte. Jetzt nutze ich weder Mac noch MySQL noch Workbench noch habe ich eine Webseite mit SQL Backend aber verdammte Hacke woran scheitern wir jetzt genau? Notfalls baust du mit der VERKETTEN Funktion in Excel für jede Zeile einen INSERT Befehl für SQL zusammen und kopierst die Befehle in dein Workbench.

Ich hab mir die Tabelle mal angeguckt und auf anhieb auch schon Fehler gefunden. Es handelt sich aber wirklich erstmal nur um 8 Zeilen, alle VARCHAR, hier mal die maximalen Längen:
spalteA, -- VARCHAR(41)
spalteB, -- VARCHAR(37)
spalteC, -- VARCHAR(108)
spalteD, -- VARCHAR(7)
spalteE, -- VARCHAR(51)
spalteF, -- VARCHAR(4)
spalteG, -- VARCHAR(255)
spalteH -- VARCHAR(14)

 

[akretschmer]

Ich hab mir die Tabelle mal angeguckt und auf anhieb auch schon Fehler gefunden. Es handelt sich aber wirklich erstmal nur um 8 Zeilen, alle VARCHAR, hier mal die maximalen Längen:

Du meinst Spalten, oder? Und was ist da jetzt falsch? Eine CSV ist halt Text, das müßte man dann prüfen, ob da z.B. korrekte DATE - Werte sind. Das zieht man dann in die 'richtigen' Tabellen.

 

[Lars Kähler]

Die acht Tabellenspalten lauten von links nach rechts:

Name | Weight | Designer | Year of release | Foundry | DIN | Annotations | Technology

»Zymarkis Octagon« heißt die letzte und hat tatsächlich auch in der alten csv nur position 31282. Abzüglich der beiden Kopfzeilen sind hier also 31.280 Schriftnamen, nach Schriftschnitten gezählt, vorhanden. Nun könnte aber sein, dass die erste Liste von Herrn Reichardt zu diesem zeitpunkt noch gar nicht mit dem PDF »Mac PostScript-Schriften« verbunden war.

 

[ukulele]

Du meinst Spalten, oder? Und was ist da jetzt falsch? Eine CSV ist halt Text, das müßte man dann prüfen, ob da z.B. korrekte DATE - Werte sind. Das zieht man dann in die 'richtigen' Tabellen.

Stimmt 8 Spalten natürlich.

Mit Fehler meinte ich Inhaltliche Dinge wie die Zeitangaben 198871990 und 18881 die wohl eher 1988-1990 und 1881 heißen sollen.

 

[akretschmer]

Stimmt 8 Spalten natürlich.

Mit Fehler meinte ich Inhaltliche Dinge wie die Zeitangaben 198871990 und 18881 die wohl eher 1988-1990 und 1881 heißen sollen.

Nun ja, bei einer Arbeitsweise wie, ich zitiere: "Es ist jetzt Jahre her, dass ich die Quelldatei – da sie ja nur aus einer einzigen Tabelle bestand –, in Excel bearbeitet und umgestellt habe. Genauergesagt hatte ich eine FileMaker-DB in MySQL importiert, von dort aus in Excel integriert und mit einer PDF-Liste »Mac PostScript-Schriften« zusammengeführt. Händisch." ist es ganz normal, daß da Schrott entsteht.

Dennoch kann man das erst einmal in eine reine ASCII-Tabelle laden und dann solange bearbeiten, bis man einzelne Spalten oder das Resultat von Selects in korrekte Datentypen casten kann. Wenn ich schon Excel lese, ...

 

[ukulele]

Dennoch kann man das erst einmal in eine reine ASCII-Tabelle laden und dann solange bearbeiten, bis man einzelne Spalten oder das Resultat von Selects in korrekte Datentypen casten kann.

Das war der Plan.

 

[Lars Kähler]

ASCII ist zuwenig, es muss schon UTF-8 sein. Es müssen auch Akzente und Umlaute sowie später außereuropäische Zeichen darstellbar sein. Vielleicht gar gleich UTF-16.

Meine Arbeitsweise mag Dir unstet und wechselhaft erscheinen, aber lass Dir gesagt sein, dass ich aus eigener beruflicher Erfahrung in Entwicklung und Produktmanagement eines international tätigen Herstellers erlebt habe, wie auch dort aus vierlerlei Gründen ganze Maschinenkonzepte gekippt werden mussten.

Was mich angeht und mein GlobalType, hatte ich einmal 600,– € in die Entwicklung eines Typo3-Templates investiert, das dann gar nicht erst zum Einsatz kam. Sowas passiert.

Nun ist aber HTML, CSS, WordPress etc. pp. so ziemlich braches Neuland für mich.

Mit der Bitte um Vergebung …

 

[akretschmer]

ASCII ist zuwenig, es muss schon UTF-8 sein. Es müssen auch Akzente und Umlaute sowie später außereuropäische Zeichen darstellbar sein. Vielleicht gar gleich UTF-16.

War von mir blöd formuliert. Ich meinte Datentyp TEXT.

Mit der Bitte um Vergebung …

Du nicht, ich.