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

S>Ок, вижу, мы опять подошли к сложному месту. Попробуем объяснить.
S>Сначала — про возможность. Если мы выбираем целочисленные ключи, то, скажем, в MS SQL нет концепции "генераторов". Identity можно узнать только пост-фактум.
S>Можно попытаться "угадать" identity, взяв, к примеру, IDENT_CURRENT(). Увы — способ ненадёжен.

Разумеется ненадёжен и никто так не делает.

Несколько раз мне приходилось генерить ключи самому.
"Приходилось" означает, что другие решения были намного дороже.
И я видел аналогичное тоже не раз.

Оперирование ключами несложное — всё их потенциальное мн-во разбивается на иерархические кластеры, выдача ключей из кластера тривиальна. Пустые места замечательно склеиваются. При незначительном усложнении (если ожидается большой трафик удалений) то удаляемые ключи можно вовсе складывать в отдельный упорядоченный агрегат, каждая попытка записи в который провоцирует операцию слияния его содержимого с пустым пространством соответствующих кластеров. Собсно, так работает любой менеджер оперативной памяти, т.е. самая сложная-навороченная схема выдачи суррогатных ключей по сложности в точности равна менеджеру памяти. А более простая — намного проще.

==============
Вдогонку. Упомянутые алгоритмы управления памятью в данном случае имеют вырожденный случай (т.е. многие ветки алгоритма заведомо отсекаются), бо всегда надо выделять свободный "участок" длиной строго равной 1.