Ich würde vorschlagen, dass Sie den Bestellvorteil nicht sehen, da die Zieltabelle keinen PK hat. Es ist also der Conversion-Overhead, den Sie sehen. Wenn es einen PK hat, müssen die 585.000 Zeilen beim Einfügen trotzdem sortiert werden. Woher weiß SQL, dass es halbsortiert ist?
Wenn es sich nun um 5.850 x 100 Zeilen-Einfügungen handelte, sehen Sie möglicherweise einige Vorteile, da die neuen Zeilen "am Ende" und nicht "in der Mitte" platziert werden, wodurch Seitenteilungen und Overhead reduziert werden.
Ich würde noch weiter gehen und sagen, dass der Artikel aus dem Jahr 2002 stammt und sich auf SQL 2000 bezieht und vom wirklichen Leben überholt wurde.
In SQL Server 2005 haben wir SEQUENTIAL GUIDs, damit streng monotone GUIDs einige Probleme lösen können. Die GUID als PK wurde auch hier gemacht:aktuelles Beispiel:INT vs Unique-Identifier for ID field in database with 3rd party links.
Wenn ein ORM die GUID als PK und nicht als natürlichen Schlüssel oder standardmäßigen int-basierten Ersatzschlüssel vorschreibt, ist dies eine schwerwiegende Einschränkung des ORM. Und ein Fall, in dem der Kundenschwanz mit dem Datenbankhund wedelt.
