Как зарезервировать значение ID-поля таблицы?

@Karbofos · Регистрация: 12.05.2008

Студворк — интернет-сервис помощи студентам

Как зарезервировать значение ID-поля таблицы для последующей возможной вставки записи с этим ID?
Т.е. до реальной вставки записи пользователь должен видеть её будущий уникальный номер. И чтобы без проблем мог делать вставку не опасаясь, что этот ID будет занят! Или не делать вставку, если передумал

@bazile · 16.04.2012, 11:24

Единственный надежный способ это делать предварительную вставкуи получать id этой записи. Как вариант можно пытаться убрать с колонки признак IDENTIY и генерить (и вставлять) id самостоятельно, но это будет ненадежно в многопользовательской среде.

Зачем вообще тебе это нужно? Поле id по своей сути это всегда служебное поле. Зачеи пользователю знать и видеть его значение?

@Karbofos · 17.04.2012, 07:11 **[ТС]**

Такое вот требование у заказчика!!!
Чтобы при заполнении формы, там был указан ID!!!
При предварительной вставке! Как мне потом убивать запись, если юзер не захочет ничего продолжать делать, а просто закроет окошко браузера?
Создать какое-нить поле флага - информирующее о действительном создании записи?
Но как потом узнать можно ли удалять записи с отсутсвующим флагом, не редактируется ли она в данный момент другим юзером
Можно открывать транзакцию конечно, но опять же, если юзер решит закрыть окно или просто будет тупо смотреть на экран в течении часа, она будет потом висеть, заблокировав при этом всю таблицу!
Будет не приятно!
Жаль, что нет сиквенсов!

@bazile · 17.04.2012, 13:25

А если схитрить и показывать максимальное значение id+1?

Но на самом деле ничего не вставлять.

@Karbofos · 17.04.2012, 14:29 **[ТС]**

если хитрить, то значит обманывать!
И запись может не лечь в базу именно под этим номером, если в это время кто-то другой добавил запись
Но решение у меня вроде появилось (пока не реализованое):
В момент открытия формы добавления записи
в базе действительно вставляем запись
берём её ID и показываем клиенту
далее удаляем запись с этим ID
а потом, если всё же юзер решить сохранить свою запись,
то делаем SET IDENTITY OFF (или ON - точно не помню) (разрешаем правку ключевого поля)
и вставляем запись с готовым ID

Как на первый взгляд решение? Должно подойти?

@bazile · 17.04.2012, 14:46

Сообщение от Karbofos

если хитрить, то значит обманывать!
И запись может не лечь в базу именно под этим номером, если в это время кто-то другой добавил запись

Все так, согласен. Просто требование глупое и поэтому я и предложил такое решение.

Сообщение от Karbofos

Но решение у меня вроде появилось (пока не реализованое):
В момент открытия формы добавления записи
в базе действительно вставляем запись
берём её ID и показываем клиенту
далее удаляем запись с этим ID
а потом, если всё же юзер решить сохранить свою запись,
то делаем SET IDENTITY OFF (или ON - точно не помню) (разрешаем правку ключевого поля)
и вставляем запись с готовым ID

Как на первый взгляд решение? Должно подойти?

Должно сработать. Сделай это все внутри хранимой процедуры и внутри транзакции чтобы в случае ошибки отключить IDENTITY_INSERT.

Такое решение будет работать только для одной таблицы так как нельзя включить IDENTITY_INSERT для нескольких таблиц одновременно. Значит в многопользовательской среде могут начаться проблемы.

Может все-таки вставдять пустую запись, получать ее id и далее делать UPDATE вместо INSERT. Чтобы таблица не замусоривовалась незаконченными записями введи поле dtCreated DEFAULT(getdate()) и сделай job удаляющий пустые записи у которых dtCreated меньше текущей даты скажем на неделю.

18.04.2012, 06:57

решение конечно не плохое, но как быть с пропуском значений в ID ? (или это не критично)

@VIT46 · 17.05.2012, 14:36

>>>то делаем SET IDENTITY OFF (или ON - точно не помню) (разрешаем правку ключевого поля)
и вставляем запись с готовым ID

А если кто-то вставит запись, то ID все-равно окажется занятым, и если даже ошибка не произойдет, то чужая запись будет затерта как я полагаю. Так что шутить с полем ID не есть хорошо

@ambarka2 · 17.05.2012, 17:45

как вариант: используй для уникального ключа поле с типом данных uniqueidentifier

получить новый можно например так:
SELECT NEWID() AS NewGUID

при INSERT-е можно не беспокоиться о вышеперечисленных проблемах

а вообще если MyId будет как ты и хотел типов: int, longint - дело говорят, вставляй пустую строчку (все остальные параметры по дефолту установи) и бери этот новый MyId через @@IDENTITY
Промежутки между - ну с этим придется мириться, да и небудет их много

@ivenhoe · 22.05.2012, 13:09

ambarka2 рулит.
Мой вариант:
Самое честное - не хитрить с ID. Я бы сделал бы так:
1. Открывается форма - делается insert для целевой таблицы и возвращаем ID этой строки в форму.
2. Во вспомогательной таблице добавляем строку с найденным ID.
3. Если пользователь ввёл данные, то делаем update целевой таблицы, и удалаяем из вспомогательной таблицы запись про ID
4. Иначе delete from target_table where ID=<тот_самый_ID> и снова удаляем строку из вспомогательной таблицы.

В итоге: честно показываем настоящий ID, и честно под ним вставляем. При этом никакой другой пользователь не займёт этот ИД. Все ID записей, которые "под вопросом", хранятся в другой таблице, т.е. исходная таблица не трогается.

Длинный и трудный метод, но, по-моему, самый честный. Способ от ambarka2 тоже честный, но мой честнее имхо

@VIT46 · 22.05.2012, 13:38

А чем обеспечивается синхронность ID этих двух разных таблиц?

@ivenhoe · 22.05.2012, 13:53

Сообщение от VIT46

А чем обеспечивается синхронность ID этих двух разных таблиц?

Не понял. Какая синхронность?

Code
1
2
3
4
5
create table assist_tbl
(
     assist_id int primary key,
     target_tbl_id <какой_там_тип>
)

При демонстрации формы в первый раз (ситуация, когда нужно показать зарезервированный ID)

Code
1
2
3
insert into target_tbl(fld1, fld2, fld_etc)
values(value1, value2, value_etc)
insert into assist_tbl(target_tbl_id) values(@@IDENTITY)

Потом когда надо удалить строчку

Code
1
delete from assist_tbl where target_tbl_id=<какая_там_строка_редактировалась>

Вроде так.

@bazile · 22.05.2012, 15:03

Сообщение от ivenhoe

Не понял. Какая синхронность?

У тебя _две_ таблицы вместо одной. Где гарантия что id этих двух таблиц будут синхронными? Ты усложняешь решение, рискуя в какой-то момент забыть что у тебя две таблицы и могут начаться проблемы. Достаточно делать "пустой" INSERT в одну таблицу, получать ID новой записи и работать с ним. Тогда никаких проблем не будет.

@ivenhoe · 22.05.2012, 15:14

Сообщение от bazile

У тебя _две_ таблицы вместо одной. Где гарантия что id этих двух таблиц будут синхронными? Ты усложняешь решение, рискуя в какой-то момент забыть что у тебя две таблицы и могут начаться проблемы. Достаточно делать "пустой" INSERT в одну таблицу, получать ID новой записи и работать с ним. Тогда никаких проблем не будет.

Зачем ID таблиц должны быть синхронными?
Фактически я предлагаю именно то, что ты описываешь. Просто в дополнительной таблице храним список ID строк целевой таблицы, которые "под вопросом". Другими словами: список ключей "сомнительных строк" храним в отдельном хранилище (вспомогательной таблице). Какая разница, совпадают ли ключи одной таблицы с ключами вспомогательной?
Зачем это нужно? На всякий случай. Автор же не говорит, зачем заказчику такой изврат нужен.
Может понадобиться, кстати, для хранения в сессии веб-приложения. Надо же как-то гарантировано решить, что данные уже точно вводиться не будут и эту строчку удалять надо, а не просто таймаут веб-сессии закончился...

Ну не знаю... Не нравится - не создавай дополнительную таблицу.

@bazile · 22.05.2012, 15:51

2 ivenhoe
Поторопился я. При предложенном тобю решении ID в самом деле не обязаны быть синхронными. Но я бы лично просто ввел в основную таблицу признак "временной" записи. Создание еще одной таблицы мне кажется излишным.

@ivenhoe · 23.05.2012, 06:28

Сообщение от bazile

Поторопился я. При предложенном тобю решении ID в самом деле не обязаны быть синхронными. Но я бы лично просто ввел в основную таблицу признак "временной" записи. Создание еще одной таблицы мне кажется излишным.

Хм..

Твоё право.
Обосную отдельную таблицу:
если речь идёт о веб-приложении, то лучше все-таки отдельную таблицу. По крайней мере, часто в отдельной таблице хранятся прочие сессионные данные, либо пользовательские данные. Веб-сессия - штука нестойкая, и если с системой работаеют несколько пользователей, то надо как-то связывать каждую "сомнительную" строку с конкретным пользователем и с его онлайн/оффлайн статусом. Иначе получится что при очередной проверке по иннициативе одного пользователя удалятся все временные записи, среди которых часть - других пользователей. А эти пользователи, мож, и не отключались - просто таймаут произошел...
Вобщем, при реализации веб-приложения я бы завел отдельную таблицу просто потому, что так удобнее для веб-приложения. При прочих равных условиях предпочёл бы твой вариант.

@bazile · 23.05.2012, 11:02

Логичнее передавать этот ID в http запросе (get или post не важно) тогда сессия не нужна, связывать "сомнительные" строки с конкретным пользователем тоже большой необходимости нет. Для определения можно ли удалить незаконченную строку можно использовать еще одно поле с датой создания - скажем удалять строки у которых эта дата старше 3 дней. Поэтому я в любом случае против отдельной таблицы.

@ivenhoe · 23.05.2012, 11:08

Сприть не буду, пусть так

Есть правда, ситуация, что отчеты по целевой таблице - раз в час, а данные 3 дня хранятся...

Новые блоги и статьи Все статьи Все блоги /
Реалии Hrethgir 01.03.2026 Нет, я не закончил до сих пор симулятор. Эта задача сложнее. Не получилось уйти в плавсостав, но оно и к лучшему, возможно. Точнее получалось - но сварщиком в палубную команду, а это значит, в моём. . .	Ритм жизни kumehtar 27.02.2026 Иногда приходится жить в ритме, где дел становится всё больше, а вовлечения в происходящее — всё меньше. Плотный график не даёт вниманию закрепиться ни на одном событии. Утро начинается с быстрых,. . .	SDL3 для Web (WebAssembly): Сборка SDL3, Box2D, FreeType и SDL3_ttf из исходников с помощью CMake и Emscripten 8Observer8 27.02.2026 Недавно вышла версия 3. 4. 2 библиотеки SDL3. На странице официальной релиза доступны исходники, готовые DLL (для x86, x64, arm64), а также библиотеки для разработки под Android, MinGW и Visual Studio. . . .	SDL3 для Web (WebAssembly): Реализация движения на Box2D v3 - трение и коллизии с повёрнутыми стенами 8Observer8 20.02.2026 Содержание блога Box2D позволяет легко создать главного героя, который не проходит сквозь стены и перемещается с заданным трением о препятствия, которые можно располагать под углом, как верхнее. . .
Конвертировать закладки radiotray-ng в m3u-плейлист damix 19.02.2026 Это можно сделать скриптом для PowerShell. Использование . \СonvertRadiotrayToM3U. ps1 <path_to_bookmarks. json> Рядом с файлом bookmarks. json появится файл bookmarks. m3u с результатом. # Check if. . .	Семь CDC на одном интерфейсе: 5 U[S]ARTов, 1 CAN и 1 SSI Eddy_Em 18.02.2026 Постепенно допиливаю свою "многоинтерфейсную плату". Выглядит вот так: https:/ / www. cyberforum. ru/ blog_attachment. php?attachmentid=11617&stc=1&d=1771445347 Основана на STM32F303RBT6. На борту пять. . .	Камера Toupcam IUA500KMA Eddy_Em 12.02.2026 Т. к. у всяких "хикроботов" слишком уж мелкий пиксель, для подсмотра в ESPriF они вообще плохо годятся: уже 14 величину можно рассмотреть еле-еле лишь на экспозициях под 3 секунды (а то и больше),. . .	И ясному Солнцу zbw 12.02.2026 И ясному Солнцу, и светлой Луне. В мире покоя нет и люди не могут жить в тишине. А жить им немного лет.

@Karbofos 0 / 0 / 0 Регистрация: 12.05.2008 Сообщений: 112

	Как зарезервировать значение ID-поля таблицы? 16.04.2012, 06:29. Показов 5976. Ответов 17 Метки нет (Все метки) Как зарезервировать значение ID-поля таблицы для последующей возможной вставки записи с этим ID? Т.е. до реальной вставки записи пользователь должен видеть её будущий уникальный номер. И чтобы без проблем мог делать вставку не опасаясь, что этот ID будет занят! Или не делать вставку, если передумал 0

@bazile 86 / 62 / 69 Регистрация: 15.03.2007 Сообщений: 6,903
	16.04.2012, 11:24
	Единственный надежный способ это делать предварительную вставкуи получать id этой записи. Как вариант можно пытаться убрать с колонки признак IDENTIY и генерить (и вставлять) id самостоятельно, но это будет ненадежно в многопользовательской среде. Зачем вообще тебе это нужно? Поле id по своей сути это всегда служебное поле. Зачеи пользователю знать и видеть его значение? 0

@Karbofos 0 / 0 / 0 Регистрация: 12.05.2008 Сообщений: 112
	17.04.2012, 07:11 [ТС]
	Такое вот требование у заказчика!!! Чтобы при заполнении формы, там был указан ID!!! При предварительной вставке! Как мне потом убивать запись, если юзер не захочет ничего продолжать делать, а просто закроет окошко браузера? Создать какое-нить поле флага - информирующее о действительном создании записи? Но как потом узнать можно ли удалять записи с отсутсвующим флагом, не редактируется ли она в данный момент другим юзером Можно открывать транзакцию конечно, но опять же, если юзер решит закрыть окно или просто будет тупо смотреть на экран в течении часа, она будет потом висеть, заблокировав при этом всю таблицу! Будет не приятно! Жаль, что нет сиквенсов! 0

@bazile 86 / 62 / 69 Регистрация: 15.03.2007 Сообщений: 6,903
	17.04.2012, 13:25
	А если схитрить и показывать максимальное значение id+1? Но на самом деле ничего не вставлять. 0

@Karbofos 0 / 0 / 0 Регистрация: 12.05.2008 Сообщений: 112
	17.04.2012, 14:29 [ТС]
	если хитрить, то значит обманывать! И запись может не лечь в базу именно под этим номером, если в это время кто-то другой добавил запись Но решение у меня вроде появилось (пока не реализованое): В момент открытия формы добавления записи в базе действительно вставляем запись берём её ID и показываем клиенту далее удаляем запись с этим ID а потом, если всё же юзер решить сохранить свою запись, то делаем SET IDENTITY OFF (или ON - точно не помню) (разрешаем правку ключевого поля) и вставляем запись с готовым ID Как на первый взгляд решение? Должно подойти? 0

ilich
	18.04.2012, 06:57
	решение конечно не плохое, но как быть с пропуском значений в ID ? (или это не критично)

@VIT46 0 / 0 / 0 Регистрация: 06.11.2008 Сообщений: 92
	17.05.2012, 14:36
	>>>то делаем SET IDENTITY OFF (или ON - точно не помню) (разрешаем правку ключевого поля) и вставляем запись с готовым ID А если кто-то вставит запись, то ID все-равно окажется занятым, и если даже ошибка не произойдет, то чужая запись будет затерта как я полагаю. Так что шутить с полем ID не есть хорошо 0

@ambarka2 0 / 0 / 1 Регистрация: 04.05.2010 Сообщений: 116
	17.05.2012, 17:45
	как вариант: используй для уникального ключа поле с типом данных uniqueidentifier получить новый можно например так: SELECT NEWID() AS NewGUID при INSERT-е можно не беспокоиться о вышеперечисленных проблемах а вообще если MyId будет как ты и хотел типов: int, longint - дело говорят, вставляй пустую строчку (все остальные параметры по дефолту установи) и бери этот новый MyId через @@IDENTITY Промежутки между - ну с этим придется мириться, да и небудет их много 0

@ivenhoe 0 / 0 / 0 Регистрация: 22.05.2012 Сообщений: 7
	22.05.2012, 13:09
	ambarka2 рулит. Мой вариант: Самое честное - не хитрить с ID. Я бы сделал бы так: 1. Открывается форма - делается insert для целевой таблицы и возвращаем ID этой строки в форму. 2. Во вспомогательной таблице добавляем строку с найденным ID. 3. Если пользователь ввёл данные, то делаем update целевой таблицы, и удалаяем из вспомогательной таблицы запись про ID 4. Иначе delete from target_table where ID=<тот_самый_ID> и снова удаляем строку из вспомогательной таблицы. В итоге: честно показываем настоящий ID, и честно под ним вставляем. При этом никакой другой пользователь не займёт этот ИД. Все ID записей, которые "под вопросом", хранятся в другой таблице, т.е. исходная таблица не трогается. Длинный и трудный метод, но, по-моему, самый честный. Способ от ambarka2 тоже честный, но мой честнее имхо 0

@VIT46 0 / 0 / 0 Регистрация: 06.11.2008 Сообщений: 92
	22.05.2012, 13:38
	А чем обеспечивается синхронность ID этих двух разных таблиц? 0

@bazile 86 / 62 / 69 Регистрация: 15.03.2007 Сообщений: 6,903
	22.05.2012, 15:51
	2 ivenhoe Поторопился я. При предложенном тобю решении ID в самом деле не обязаны быть синхронными. Но я бы лично просто ввел в основную таблицу признак "временной" записи. Создание еще одной таблицы мне кажется излишным. 0

@bazile 86 / 62 / 69 Регистрация: 15.03.2007 Сообщений: 6,903
	23.05.2012, 11:02
	Логичнее передавать этот ID в http запросе (get или post не важно) тогда сессия не нужна, связывать "сомнительные" строки с конкретным пользователем тоже большой необходимости нет. Для определения можно ли удалить незаконченную строку можно использовать еще одно поле с датой создания - скажем удалять строки у которых эта дата старше 3 дней. Поэтому я в любом случае против отдельной таблицы. 0

@ivenhoe 0 / 0 / 0 Регистрация: 22.05.2012 Сообщений: 7
	23.05.2012, 11:08
	Сприть не буду, пусть так Есть правда, ситуация, что отчеты по целевой таблице - раз в час, а данные 3 дня хранятся... 0