Насколько я понял, речь об MS SQL.
xdxЕсть поле с типом данных "uniqueidentifieer" (GUIDE)
Оно ключевое, соответсвенно, по нему автоматически был создал кластерный уникальный индекс.
Создавайте ключ с указанием NONCLUSTERED.

xdxА имеет ли смысл делать это поле кластерным?
Мне кажется сортировка индекса по этому полю бессмысленна, зачем тогда "напрягать сервер" ?
Но по нему очень часто идет обращение.Если нет более подходящего кандидата, что маловероятно, то на здоровье.
1. Будете избавлены от bookmark lookup при поиске по этому полю. Чисто теоретически будете избавлены от так называемого "hot spot", хотя вряд ли вы с ним встретитесь в принципе, с учётом задаваемых вопросов. В то же время, начиная с версии 2005, новые значения GUID могут быть не только случайными, но и последовательными - NEWSEQUENTIALID().
2. В пределах страницы никакой явной сортировки не выполняется. Порядок записей определяется во внутреннем массиве смещений страницы данных.
3. В целом же, особого смысла в кластеризации по суррогатным значениям, нет. Смысл кластеризации прежде всего в хранение подобного рядом, а на это впрямую влияет характер типовых запросов к данной таблице.

xdxпримерно тогда суть такая, если это конечно возможно:
1. Поле GUIDE слелать ключевым (уникальным), но не кластерным
2. По полю "дата создания" сделать кластерный индекс.
Будет ли данный подход оптимальным? Ну или хотя бы правильным? :-)Возможно. Хотя чисто для "сферического коня в вакууме" лучше, возможно, так
(GUID) - PRIMARY KEY NONCLUSTERED
("дата создания", GUID) - UNIQUE CLUSTERED
Кластерный индекс всегда уникален, если вы сами этого явно не указываете, то к неуникальному значению автоматически будет генерироваться некое дополнение, гарантирующее уникальность для каждой записи. Таким образом, кластерный индекс лучше создавать явно уникальным. Поля кластерного индекса в некластерном индексе используются только один раз, т.е., в указанный выше PRIMARY KEY будет добавлено только значение "дата создания", поле GUID не будет дублироваться. В случае, если бы в кластерный индекс был включено только поле "дата создания", то в PK было бы включено три сущности: GUID, "дата создания" и "unique tail", дополняющий кластерный индекс до уникальности.

xdxА получится ли потом по индексу ("дата создания", GUID) настроить секционирование?
Или секционирование легко построится по полю "дата создания" ?

Тут ни каких проблем не возникнет?Так всё в BOL описано. В случае секционирования есть определённые требования. Вот одно из них, самое критичноеавторPartitioning columns must be a part of the primary key of the tableТ.е., надо будет сделать ("дата создания", GUID) - PRIMARY KEY CLUSTERED. И тогда (GUID) может сделать просто UNIQUE, этого достаточно, чтобы организовать по нему ссылочную целостность(FOREIGN KEY), если понадобится.

xdxЧто-то это поле GUIDE мне нравится все меньши и меньше.А зачем эмоциональная оценка ? У GUID достаточно чёткая область использования, когда без особых усилий нужно получить "уникальный" суррогатный ключ , обладающий определёнными свойствами. В остальных случаях, его применимость не очень оправдана, IMHO.