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

V>>Несколько раз мне приходилось генерить ключи самому.
V>>"Приходилось" означает, что другие решения были намного дороже.
S>Ок, давайте теперь поговорим о нужде знать ID ещё до вставки.

Закинуть за раз некий развесистый граф данных из многих таблиц.
Когда идёт большой трафик таких событий, то и выхода другого часто нет.
В этом случае клиент запрашивает сначала целый диапазон ID (целый участок "свободной памяти"), а потом пихает эти ID-шки.


S>Я видел решения, которые устроены примерно так, как ты описал (хотя решительно не понимаю, как там можно оперативно возвращать неиспользованные ключи, не встревая в 2phase commit и прочий хардкор).

Оно принципиально хорошо живёт только в случае выделенного сервера приложений, т.к. такой временный агрегат для хранение еще не слитых ID должен быть (1) максимально легковесным и (2) иметь не реляционную природу, а иерархическую/кластерную. Обычно "оно" представляет из себя дерево тех самых кластеров (двоичное дерево для многих популярных алгоримов управления памятью), где к каждому кластеру привязан тот самый вязанный список свободной памяти, которую пока невозможно слить в непрерывные участки по основанию логарифма кластера. Инфа о самих кластерах может сохраняться в таблицах, но каждый новый кластер, взятый/порождённый для раздачи ID, предварительно инициализируется в оперативной памяти, т.е. в нём ищутся те самые свободные участки (если есть).


S>В тех случаях, когда я их видел, "необходимость" была продиктована достаточно искусственными причинами.

Какими например?

У меня-то причина более чем на поверхности — взять даже банальный master-slave.
Я хорошо представляю себе как закинуть в одной операции одну строку из master и к ней несколько из slave без заведомого знания про ID master-а, но плохо представляю как закинуть за раз несколько строк master-a с соотв. привязанными slave без предварительного знания ID master-ов.

Более того, в первом случае придётся еще озаботиться ожиданием ответа из вызова серверной процедуры, а в трехзвенке (не HTTP, а в классическом сервере приложений) всё-таки намного удобней иметь АПИ в котором львиная доля трафика представляет из себя просто обмен асинхронными сообщениями. Т.е. отправили данные на сервер, но локально имеем возможность продолжать что-то с данными делать. Через некоторое время асинхронно придёт оповещение об успешности/неуспешности операции, но в этот промежуток времени на клиенте нет надобности ждать возвращённый в синхронной манере ID.