Бих предложил да не виждате ползата от поръчката, тъй като целевата таблица няма PK. И така, виждате преобразуването. АКО има PK, 585k редове все още трябва да бъдат сортирани при вмъкване. Как SQL знае, че е полусортирано?
Сега, ако беше 5850 х 100 вмъквания на редове, тогава може да видите известна полза, защото новите редове ще вървят „в края“, а не „в средата“, така че ще намалите разделянето на страниците и надписите.
Бих отишъл по-далеч и бих казал, че статията е от 2002 г. и е за SQL 2000 и е изпреварена от реалния живот.
В SQL Server 2005 имаме ПОСЛЕДОВАТЕЛНИ GUID, за да позволим на строго монотонни GUID за решаване на някои проблеми. GUID като PK е направен и тук:скорошен пример:INT срещу уникален идентификатор за полето ID в база данни с връзки на трети страни.
Ако ORM диктува GUID като PK, а не естествен ключ или стандартен сурогатен ключ, базиран на int, това е сериозно ограничение на ORM. И случай на опашката на клиента, която размахва кучето от базата данни.
