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

V>Закинуть за раз некий развесистый граф данных из многих таблиц.
Непонятно. Без конкретного примера — ничего непонятно.

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

V>Оно принципиально хорошо живёт только в случае выделенного сервера приложений, т.к. такой временный агрегат для хранение еще не слитых ID должен быть (1) максимально легковесным и (2) иметь не реляционную природу, а иерархическую/кластерную. Обычно "оно" представляет из себя дерево тех самых кластеров (двоичное дерево для многих популярных алгоримов управления памятью), где к каждому кластеру привязан тот самый вязанный список свободной памяти, которую пока невозможно слить в непрерывные участки по основанию логарифма кластера. Инфа о самих кластерах может сохраняться в таблицах, но каждый новый кластер, взятый/порождённый для раздачи ID, предварительно инициализируется в оперативной памяти, т.е. в нём ищутся те самые свободные участки (если есть).
Всё равно непонятно. Вот я начал вставлять с использованием свежевыбранного ID. При этом он уже из "кластера" ушёл — иначе в параллельной транзакции его схватит кто-то ещё.
Тут пропала связь с RDBMS. Как мне понять, транзакция закоммитилась или нет? Всё, ID утёк.
Восстановление состояния каунтеров потребует перевода всей системы в readonly и переинвентаризации идентификаторов.
Альтернатива: забить на "дырки", как и делают все СУБД.

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

begin tran
insert into master (name) values ('Первыйнах')
set @ID1 = SCOPE_IDENTITY()
insert into slave(masterId, Name) values (@ID1, 'Первый-1')
insert into slave(masterId, Name) values (@ID1, 'Первый-2')
insert into master (name) values ('Между первой и второй перерыва вовсе нет')
set @ID2 = SCOPE_IDENTITY()
insert into slave(masterId, Name) values (@ID2, 'Второй-1')
insert into slave(masterId, Name) values (@ID2, 'Второй-2')
commit tran

Это — пример на технологиях каменного века. С тех пор придумали output clause, которое позволяет делать и более впечатляющие трюки.
V>Более того, в первом случае придётся еще озаботиться ожиданием ответа из вызова серверной процедуры,
Зачем ждать-то? fire and forget.
V> а в трехзвенке (не HTTP, а в классическом сервере приложений) всё-таки намного удобней иметь АПИ в котором львиная доля трафика представляет из себя просто обмен асинхронными сообщениями. Т.е. отправили данные на сервер, но локально имеем возможность продолжать что-то с данными делать. Через некоторое время асинхронно придёт оповещение об успешности/неуспешности операции, но в этот промежуток времени на клиенте нет надобности ждать возвращённый в синхронной манере ID.
Отож. Всё так. И по-прежнему клиенту не обязательно знать идентификаторы заранее. Никаких тебе заморочек с над-реляционными кластерами.