Sugeruję, że nie widzisz korzyści z zamówienia, ponieważ tabela docelowa nie ma PK. Widzisz więc narzut konwersji. JEŚLI ma PK, 585k wierszy musi nadal być posortowane przy wkładaniu. Skąd SQL wie, że jest częściowo posortowany?
Teraz, jeśli było to 5850 x 100 wstawek wierszy, możesz zauważyć pewne korzyści, ponieważ nowe wiersze będą umieszczane „na końcu”, a nie „w środku”, co zmniejsza podziały stron i narzuty.
Pójdę dalej i powiem, że artykuł jest datowany na 2002 rok i dotyczy SQL 2000 i został wyprzedzony przez prawdziwe życie.
W SQL Server 2005 mamy sekwencyjne identyfikatory GUID, aby umożliwić ściśle monotoniczne identyfikatory GUID w celu rozwiązania niektórych problemów. Tutaj też zrobiono GUID jako PK:ostatni przykład:INT vs Unique-Identifier dla pola ID w bazie danych z linkami stron trzecich.
Jeśli ORM określa identyfikator GUID jako PK, a nie klucz naturalny lub standardowy klucz zastępczy oparty na int, jest to poważne ograniczenie ORM. I przypadek ogona klienta machającego psem bazy danych.
