Здравствуйте, Sharov, Вы писали:

S>Такой вопрос, а для кого эти стратегии расчитаны? Т.е. это должен быть один экземпляр приложения,
S>который работает с бд. Как множество микросервисов с SequenceHiLo не пересекутся тогда?
S>Т.е. в рамках одного процесса все это можно контролировать, а если процессов больше?

Нет, не пересекутся. Смотри.

 CREATE SEQUENCE [dbo].[MySequence] START WITH 1 INCREMENT BY 10;

 SELECT NEXT VALUE FOR [dbo].[MySequence]; -- (1) возвращается 1

 SELECT NEXT VALUE FOR [dbo].[MySequence]; -- (2) возвращается 11

Получение NEXT VALUE синхронизованы на уровне движка БД, т.е. там что-то типа такого:

lock(syncLock) {
  var old = current
  current += 10;
  return old;
}

В (1) мы получили значение 1. И мы знаем, что шаг sequence = 10.
Это значит, что значения 1,2,3...10 можно спокойно использовать в качестве идентификаторов, т.к. следующий кто вызовет sequence получит уже 11.
Аналогично после шага (2) можно использовать 11,12...20 и т.д.

Это, к слову, не класический алгоритм HiLo (класический можешь загуглить), но там смысл такой же.

S> Если короче-- каковы сценарии hilo?

Минимизировать взаимодействие в БД при вставке графа объектов.
Если все ID уже назначены на клиентской стороне, то можно открыть транзакцию отправить все SQL INSERT и быстренько закомититься.
Не нужно после каждой вставки получать обратно SCOPE_IDENTITY(), как в случае с IDENTITY-столбцом.
В итоге вставка быстрее, транзакция короче, локов/дедлоков меньше.

Плюс, например, в логи можно писать ID-сущностей, не делая каждый раз SaveChanges.

Или иногда бывает нужна сквозная идентификация всех объектов в БД и поэтому отдельный IDENTITY на каждой таблицы не подходит.