Ich möchte noch ergänzen, dass das Bedürfnis nach einer eindeutigen ID natürlich legitim ist. Was und wie Du aber auch immer importierst, die zu importierenden Daten sollten über solch ein eindeutiges Merkmal bereits verfügen, notfalls über mehrere Felder und idealer Weise auch gegenüber den bereits importierten Daten. Ansonsten holst Du Dir die Leichen reihenweise in den Keller.
Schau Dir mal Literatur zum Thema ETL an. Ganz grob:
Daten temporär in der
DB bereitstellen (z.B. via ExternalTable)
Daten aufbereiten (z.B. Dubletten entfernen, plus Rückmeldung / Log)
Daten dann mit System-/Produktivdaten abgleichen und ggF. importieren.
Dabei gehst Du sehr wahrscheinlich Satz für Satz durch die neuen Daten und schaust wo und wie Du sie unterbringst. (Wiederum mit Rückmeldung bzw. Log für automatisierte Prozesse)
Konvertierung:
Es ist stark anzunehmen, dass Deine
CSV Daten im Klartext dort stehen und Integer bspw nicht 2 oder 4 Byte binär codiert sind.
Also Integer auch als Varchar einlesen mit Längenangabe entsprechend dem
CSV.
P.S.: Wenn Du aus der
DB dann auf die "integer" Daten zugreifst, musst Du konvertieren.
Also beim Insert in die Zieltabelle z.B..
Zum 1ten Absatz:
Also am besten mit einem 2ten Integer Feld (in dem bereits die Autoinc enthalten ist)??
zum 2ten Absatz:
Nenn mir doch mal eine deutschsprachige Literatur zum Thema ETL (externalTabelle?), welche möglichst einfach gehalten ist. Vielleicht gibt's da noch etwas was ich bei meiner Recherche übersehen habe.
zum 3tenAbsatz (Konvertierung):
Anbei zwei Screenshots, beide zeigen die Ergebnisse der external Tabelle aus IBexpert personnel.
Der eine Screenshot zeigt das Importergebnis von CHAR, der andere das Importergebnis von VARCHAR an beide mit Länge 10.