Ich hatte vor ein paar Jahren ein sehr ähnliches Problem. Der (nicht unwesentliche) Unterschied: Ich musste den "Baum" innerhalb der selben Tabelle duplizieren, so dass der Primärindex auf keinen Fall übernommen werden konnte.
Ich habe recht lange nach einer eleganten Lösung gesucht, die möglichst innerhalb von
SQL besteht, leider auch ohne Erfolg. Letztlich habe ich es dann eben auch ausprogrammiert (allerdings in Delphi), und jedes Insert fein säuberlich von Hand gebaut. Besonders fies dabei ist ja: Man kann die Parent-IDs erst dann in der Kopie neu setzen, wenn die Kopie bereits besteht - vorher sind die Auto-Werte ja unbekannt. Daher wird jedes Insert noch mit einem Select und einem Update garniert, und man muss sich Gedanken darüber machen, wie man die ursprünglichen Abhängigkeiten effizient so puffert, dass sich die Parent-IDs nach dem Einfügen aller Knoten/Sätze noch sauber nachvollziehen lassen. (Besonders hübsch bei Graphen.) Bei ein paar zig Datensätzen ist das verschmerzbar, darüber wird es aber dann doch vergleichsweise langsam.
Da du aber in eine frische und daher vermutlich leere Tabelle kopieren willst, könnte sich das doch deutlich vereinfachen. Vor allem, wenn es eine nicht allzu oft durchgeführte Operation ist (seltener als alle paar zig Minuten): Einfach den Autoinc für die neue ID-Spalte aus machen, den Index darauf droppen, ganz naiv kopieren, und nachher Index und Autoinc wieder an schalten. Eventuell lässt sich das droppen des Index sogar noch vermeiden, jedoch weiss ich nicht ob das praktisch so wirklich klappt: Wenn man die Inserts innerhalb ein und der selben Transaktion durchführt,
sollte sich das DMBS nicht über ungültige Zwischen-States beklagen. Eventuell! Wenn das geht, würde es auch für eine oft gemachte Routine taugen.
Wenn die neue Tabelle erst mit Anlegen der Kopie überhaupt erst erstellt wird, ließe sich daraus auch mit einem einigermaßen effizienten
SQL Script was machen. Quasi:
SQL-Code:
CREATE TABLE foo ... // kein autoinc und index setzen!
INSERT INTO foo (id, bar, ...) VALUES (id1, blub), (id2, blub), ...
ALTER TABLE foo ... // autoinc setzen und index erzeugen
Mal so als lose Ideensammlung, die unverschämt ungetestet ist
(Randnotiz: Der
DP SQL Highlighter mag "//" nicht als Kommentar-Token. Ist das non-standard?)
"When one person suffers from a delusion, it is called insanity. When a million people suffer from a delusion, it is called religion." (Richard Dawkins)