ASCRUSЕсли есть глобальные инкременты или сиквенсы или нет репликаций, то я лично потребности в GUID вообще не ощущаю - наоборот, если его использовать в качестве PK, то мы получаем одни недостатки в виде увеличения обьема данных и индексов, невозможности сортировки по нему, так как значения выдаются неупорядоченно и еще кучу геммора. Лично для меня GUID хорош только для ввода уникального обозначения данных для разных систем, то есть при интеграции и передаче данных, но никак для хранения в качестве основного идентификатора и работы с ним (та же песня, что и с XML).Зачем вам сортировка по PK? Так уж ли сильно увеличится объем? И что за куча гемора?
Не делайте голословных утверждений. Если вы их не используете - это ваше дело.
Вы просто не умеете их готовить :)

Еще XML зачем-то приплели. Он-то чем вам не угодил? Или то же по старчески :)

ASCRUSPK - это индекс, индекс не любит больших значений, тем более когда они прыгают во все стороны - не так ли ? Это раз. GUID явно занимает не 4 байта и не 8 - прикиньте себе обьем увеличения на базе PK-FK с GUID, пожалейте оптимизатор и кэш сервера при обработке больших обьемов данных - это два. XML приплел потому, что сейчас тоже этот разнесчастный формат передачи данных пытаются использовать как формат их хранения - это три. Я неиспользую GUID, потому что убедился в их неэффективности по сравнению с инкрементами - это четыре. И мне их не надо готовить, потому что у меня есть функция получения нового инкремента без физической вставки записи и глобальные инкременты, автоматически ведущиеся в разрезе каждой реплицируемой БД - это пять. Отсюда мне думается, что GUID удобно использовать как вторичный идентифицирующий ключ, для связи данных с другими системами, но уж никак ИК. IMHO.Да перестаньте вы в самом деле про объем. Разница в 8 - 12 байт даст вам 12Mb на 1млн записей - по нынешним временам наплевать и растереть.
Какого-либо существенного замедления скорости шарканья по индексу на больших таблицах замечено не было.
По поводу прыганий индекса - есть положительный момент - не смотря на необходимость деления конечных страниц, получается сбалансированное B-дерево из за равномерной вероятности распределения индекса.
Впрочем, переубеждать вас не собираюсь - дело не благодарное. Не хотите - не пользуйтесь.

XML для хранения то же оправдан как способ денормализации в некоторых случаях. Уже много на этом форуме дискутировалось по этому поводу. Я не собираюсь вступать сейчас в полемику.
Однако, хотите вы, не хотите, XML для хранения уже не остановить.
Мы пока не пользовались - нужды нет. Но время покажет.