Hi Giubt es eine Möglichkeit ein csv mit einigen 10.000 Einträgen automatisch zu scannen um den jeweils "kleinsten" Datentyp jeder Spalte zu definieren?
Klar, mit einem kleinen Programm in der Programmiersprache deiner Wahl ist das kein Problem.
In die Tabellenkalkulation deines Vertrauens importieren und Min/Max über die Spalten bilden. Volker
:
Bearbeitet durch User
Klar. Alles in eine temporäre Tabelle mit Textspalten importieren, dann über die Spalten iterieren und via SELECT checken, auf welchen Typ man noch ohne Fehler CASTen kann. Dann entsprechende permanente Tabelle anlegen und umkopieren.
Robert schrieb: > Giubt es eine Möglichkeit ein csv mit einigen 10.000 Einträgen > automatisch zu scannen um den jeweils "kleinsten" Datentyp jeder Spalte > zu definieren? Ja.
Volker Z. schrieb: > In die Tabellenkalkulation deines Vertrauens importieren und > Min/Max > über die Spalten bilden. > Volker Da er aber den Datentypen ermitteln will, bringt min/max nicht die Lösung. Aber mit (max(length()) oder ähnliches kommt man sicherlich weiter.
Jens G. schrieb: > Da er aber den Datentypen ermitteln will Dazu müsste er erst mal klarstellen, was er unter dem "kleinsten Datentyp" versteht - so eine Definition gibt es garnicht. Jens G. schrieb: > mit (max(length()) Vielleicht meint er das, vielleicht auch nicht. Und wenn, ist 16bit unsigned kleiner als 16bit signed?? Georg
Robert schrieb: > ein csv mit einigen 10.000 Einträgen Nachtrag: im csv stehen nicht Typen sondern Werte. 123 passt in 8bit, aber das besagt nichts über den Typ, auch ein 32bit Integer oder auch eine Fliesskommazahl kann den Wert 123 haben. Aber vielleicht ist es auch ein String, wie eine Telefonnummer? Georg
Robert schrieb: > Giubt es eine Möglichkeit ein csv mit einigen 10.000 Einträgen > automatisch zu scannen um den jeweils "kleinsten" Datentyp jeder Spalte > zu definieren? https://csvkit.readthedocs.io/en/latest/
Georg schrieb: > Jens G. schrieb: >> mit (max(length()) > >> Da er aber den Datentypen ermitteln will > >Dazu müsste er erst mal klarstellen, was er unter dem "kleinsten >Datentyp" versteht - so eine Definition gibt es garnicht. Muß man bei Dir immer alles definieren, damit Du es begreifst? > Vielleicht meint er das, vielleicht auch nicht. Und wenn, ist 16bit > unsigned kleiner als 16bit signed?? Nein, aber ein char(10) ist kleiner als char(255)
:
Bearbeitet durch User
Jens G. schrieb: > Georg schrieb: >> Jens G. schrieb: >>> mit (max(length()) >> >>> Da er aber den Datentypen ermitteln will >> >>Dazu müsste er erst mal klarstellen, was er unter dem "kleinsten >>Datentyp" versteht - so eine Definition gibt es garnicht. > > Muß man bei Dir immer alles definieren, damit Du es begreifst? Vielleicht ja nicht alles, aber zumindest einmal irgendwas. Wie z.B. wovon der kleinste Datentyp? Eine Programmiersprache? Irgendeine Form von Datenbank (da er im Titel ja explizit Datenbanken erwähnt)? Excel? Serialisierungsframework? >> Vielleicht meint er das, vielleicht auch nicht. Und wenn, ist 16bit >> unsigned kleiner als 16bit signed?? > > Nein, aber ein char(10) ist kleiner als char(255) Sofern wir von einer C-artigen Sprache sprechen, sind die Datentypen gleich groß. In C oder C++ kann es aber je nach Compiler sein, dass 255 gar nicht in einen char passt. Das ist eben das Problem: Man kann nur mit einem "sofern", "je nach dem", "vielleicht", … antworten, weil der Frage wichtige Informationen fehlen.
:
Bearbeitet durch User
Meiner Meinung nach muss er doppelt scannen. JEDE Feld deklarieren Dann in einer Schleife JEDES Feld auf die typischen Merkmale überprüfen, Also 123456789 , . <- NUR Das gleich Zahlenfeld. Nun muss er sich auch noch die Größe des Feldes merken. Sobald das Feld ein anderes Zeichen enthält, werden alle Felder der Spalte zu Textfeldern erklärt. Nun wider die Länge. Je nach Ziel-Datenbank ist der Wert 255 wichtig. Danach muss die Spalte zu einer Memo-Feld werden. Das Risiko dabei ist, das wenn neue Daten kommen, und die größer sind man Stress hat. Weshalb ich Größen immer sehr Großzügig auslege. In der heutigen Zeit halte ich die Größe einen Feldes einer Datenbank nicht mehr für sooo wichtig wie vor 30 Jahren, wo ich mit jeden Bytes geizen musste. Der Tipp mit Excel o. Access geht auch. Wenn man es nur einmal machen muss. Aber wie schon gesagt, für lausige 40.000 Datensätze ich mir der Aufwand zu hoch. Davon abgesehen hat man noch den Nebeneffekt das man Eingabe-Masken etc. auf die Länge einstellen muss, um Überlauf/Datenbankfehler/Datenverlust etc. zu vermeiden.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.