День 1284. #ЗаметкиНаПолях Генерация Сортируемых Guid с Помощью NewId. Начало NewId предназначен случаев, когда вам нужен уникальный идентификатор, но, по возможности, сортируемый и предсказуемый, например для первичных ключей в базах данных. Большинство используют: - int и позволяют базе данных генерировать первичный ключ при вставке строки, - Guid, генерируя идентификатор в своём приложении и вставляя его в строку. Рассмотрим плюсы и минусы каждого подхода. 1. Генерация в базе данных Плюсы: - Первичные ключи получают красивые, монотонно возрастающие (и обычно последовательные) идентификаторы. - Упрощается работа с тестовыми данными. Идентификаторы часто появляются в URL-адресах, и простые последовательные идентификаторы очень удобно использовать. Минусы: - Невозможность использования некоторых паттернов проектирования. Например, распространённый подход к идемпотентности заключается в создании идентификатора на клиенте и отправке его в запросе. Это устраняет дублирование и гарантирует, что вы не вставите один и тот же объект дважды, так как легко обнаружить повторяющиеся запросы на вставку. Такой подход обычно невозможен с идентификаторами, сгенерированными базой данных. - Усложнение кода вставки, чтобы возвращать сгенерированные идентификаторы. ORM, такие как EF Core, инкапсулируют эту логику, но, например, при использовании Dapper, вам придётся это делать самому. - При вставке тысяч строк в секунду, «блокировка» базы данных вокруг генератора идентификаторов иногда может стать узким местом. - Масштабирование «вширину» затруднено из-за необходимости координировать идентификаторы между всеми серверами. 2. Генерация GUID на клиенте Плюсы: - Лёгкость. Все современные языки имеют доступные генераторы UUID; в .NET это Guid.NewGuid(), который возвращает случайный 128-битный идентификатор. Генерация его на клиенте и вставка позволяет не беспокоиться о том, что было сгенерировано в БД. В EF Core или Dapper, Postgres или SqlServer - всё одинаково. Данные перемещаются только в одном направлении: от клиента к базе данных. - Лёгкий доступ к различным шаблонам идемпотентности. Если запрос на вставку завершается сбоем из-за ошибки сервера, можно безбоязненно отправить тот же запрос ещё раз, зная, что сервер сможет идентифицировать возможный дубликат (т.к. ключ тот же), и избежать создания повторяющихся сущностей. Случайность Guid - это и их сила, и их слабость. Минусы: - Для разработчика, тестирующего код, с /my-entity/be170000-f22d-18db-02db-08da21702e9f определённо не так просто работать, как с /my-entity/1. - В базе данных эта случайность идентификаторов может привести к серьезной фрагментации индекса, что увеличивает размер вашей базы данных и влияет на общую производительность. Также UUID являются 128-битными по сравнению с 32-битными целыми числами, поэтому больше и чистый размер хранимых данных. Окончание следует… Источник: https://andrewlock.net/generating-sortable-guids-using-newid/