Мне не нравятся UUID для "первичных ключей" в целом, однако распределенная модель - это модель, в которой они достаточно хорошо подходят, при условии, что UUID генерируется соответствующим образом ;-) В зависимости от других проблем, он все еще может не быть первичный ключ , а скорее другой ключ-кандидат (представьте себе «альтернативный PK», который поддерживается уникальным индексом).
Мне известны две "проблемы":
UUID похожи на IPv6.Они длинные и, следовательно, не являются самыми дружественными для человека ценностями.С другой стороны, они очень последовательны в форматировании и их легко обнаружить.Приобретите навыки копирования и вставки.
Полностью случайные UUID имеют тенденцию фрагментировать индексы;При использовании в качестве PK, который обычно кластеризован (по сравнению с индексом, который может быть просто указателем на запись), это может привести к ужасной фрагментации. Однако;
Хороший план обслуживания базы данных должен решить эту проблему: переиндексировать фрагментированные индексы по расписанию .
Специальные схемы генерации UUID, такие как NEWSEQUENTIALID
в SQL Server , хотя и «более предсказуемы», но также могут генерировать монотонно растущие значения и, таким образом, смягчать фрагментацию индекса / кластера.
Счастливого кодирования.