ich versuche vergeblich eine CSV-Datei in meine Datenbank zu importieren.
Er bricht mir immer mit der Fehlermeldung ab:
„Duplicate Entry ‚10‘ for key 1“
Und das kann ich einfach nicht nachvollziehen.
Die Struktur sieht so aus:
CREATE TABLE plz_adr (
von_plz varchar(8) NOT NULL,
bis_plz varchar(8) NOT NULL,
name1 varchar(50) NOT NULL,
name2 varchar(50),
lager_nr varchar(8) NOT NULL,
strasse varchar(50) NOT NULL,
plz varchar(8) NOT NULL,
ort varchar(50) NOT NULL,
telefon varchar(30),
fax varchar(30),
email varchar(50),
handy1 varchar(30),
handy2 varchar(30),
handy3 varchar(30),
handy4 varchar(30),
idnr varchar(10) NOT NULL auto_increment,
PRIMARY KEY (idnr),
KEY idnr (idnr),
UNIQUE idnr_2 (idnr)
);
Wenn ich die Fehlermeldung richtig interpretiere, meint phpmyadin, dass es einen doppelten Eintrag für den
Schlüssel ‚idnr‘ geben soll.
Aber wie soll den ein auto-increment-Feld je einen doppelten Eintrag erhalten?
Bei den Daten, die übernommen werden, sind zwar zahlreiche doppelte Daten enthalten, aber das spielt ja auch
keine Geige, oder? Geht doch nur um die Unique-Keys, die hier Probs machen können und das ist halt nur idnr.
IDNR ist übrigens nicht in der CSV-Datei enthalten.
Meine Vermutung ist, dass Du den Unique-Key auch in der CSV-Datei mitgeben musst, da das Import-Utility wahrscheinlich nicht gleich wie ein normaler Insert funktioniert. Sondern die Daten nur in die Tabelle kopiert.
Eine Bemerkung zu deiner Tabelle:
Warum verwendest Du VARCHAR und nicht CHAR? Wenn MySQL wie andere Datenbanken funktioniert, brauchst Du unnötig Speicherplatz, da bei es im Hintergrund bei einem VARCHAR-Feld noch ein Längenfeld (i.R. Integer) gibt, welches die Länge des Feldinhaltes gespeichert hat.
Meine Vermutung ist, dass Du den Unique-Key auch in der
CSV-Datei mitgeben musst, da das Import-Utility wahrscheinlich
nicht gleich wie ein normaler Insert funktioniert. Sondern die
Daten nur in die Tabelle kopiert.
Nach meinen bisherigen Erfahrungen brauchte ich dies bisher nicht. Da es ein Auto-Increment ist, schien mir das sogar eher falsch. Aber nicht desto trotz hab ich auch dies bereits probiert. Mit dem selben Ergebnis
Eine Bemerkung zu deiner Tabelle:
Warum verwendest Du VARCHAR und nicht CHAR? Wenn MySQL wie
andere Datenbanken funktioniert, brauchst Du unnötig
Speicherplatz, da bei es im Hintergrund bei einem VARCHAR-Feld
noch ein Längenfeld (i.R. Integer) gibt, welches die Länge des
Feldinhaltes gespeichert hat.
Klingt recht einleuchtend. Zu meiner Verteidigung hab ich mal irgendwo gelesen, dass varchar besser wäre. Zum Einen brauch ich mir keine Gedanken machen, wie lang der Char nun wirklich wird (?) und zum Anderen würde ein 50 Varchar in der Tabelle, wenn nicht gefüllt, keine 50 Zeichen besetzen, sondern nur die tatsächliche Länge (?).
Erstmal Danke für Deine Antwort, aber leider noch keine Lösung.
Eine Bemerkung zu deiner Tabelle:
Warum verwendest Du VARCHAR und nicht CHAR? Wenn MySQL wie
andere Datenbanken funktioniert, brauchst Du unnötig
Speicherplatz, da bei es im Hintergrund bei einem VARCHAR-Feld
noch ein Längenfeld (i.R. Integer) gibt, welches die Länge des
Feldinhaltes gespeichert hat.
Ja, aber die Feldlänge ist fest - wenn Du also den Namen Simon abspeichern willst, brauchst Du immer 30 Zeichen, bei Varchar 5 + Längenbytes. Bei den meisten Feldern der Tabelle hier ist Varchar günstiger; Ausnahmen vielleicht PLZ usw.
Klingt recht einleuchtend. Zu meiner Verteidigung hab ich mal
irgendwo gelesen, dass varchar besser wäre.
Je nach Anwendungsfall, ja. Generell kann man das nicht sagen, aber bei den allermeisten Anwendungsfällen schon.
Zum Einen brauch
ich mir keine Gedanken machen, wie lang der Char nun wirklich
wird (?) und zum Anderen würde ein 50 Varchar in der Tabelle,
wenn nicht gefüllt, keine 50 Zeichen besetzen, sondern nur die
tatsächliche Länge (?).
Beides stimmt, letzteres : tatsächliche Länge + Längenbytes (abhängig von der Implementierung, aber meistens 2 Bytes).
Beide Foren sind für alle größeren DB-Systeme gedacht, dieses Forum für SQL und Programmierung, das allgemeine Forum für Installation, Konfiguration und allem andren drumherum.
Aber es stimmt, dass dieses Forum ganz kurz nach der Neureform nur für MySQL gedacht war, das wurde dann aber wieder über den Haufen geworfen.
