Используются ли числовые первичные ключи удаленных записей в базе данных повторно для будущих новых записей?

StackOverflow https://stackoverflow.com/questions/253522

Вопрос

Например, если у меня есть поле с автоматической нумерацией, я добавляю новые записи без указания этого поля и позволяю движку DB выбрать его за меня.
Итак, выберет ли он номер удаленной записи?Если да, то когда?

// SQL Server, MySQL.//

Последующий вопрос: Что происходит, когда в ядре базы данных заканчиваются числа для использования в качестве первичных ключей?

Это было полезно?

Решение

нет.цифровые первичные ключи не будут использоваться повторно, за исключением случаев, когда вы укажете их вручную (вам действительно следует избегать этого!).

Другие советы

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

Как правило, нет, номера не используются повторно.

Однако в таких продуктах, как Oracle, вы можете указать генератор последовательностей, который будет циклически повторяться и использовать числа.

Является ли это количеством удаленных записей или нет, это проблема ваших приложений.

Этот вопрос необходимо уточнить:

... " с последовательностями Oracle "

... " со столбцами автономного номера MySQL "

... и т. д.

Пока вы правильно создаете таблицу, вы не будете повторно использовать числа. Однако вы можете СБРОСИТЬ столбец идентификаторов (В любом случае, в MSSQL), используя следующее:

- введите номер последней действительной записи в таблице, а не следующий номер, который будет использоваться

CHCCKIDENT DBCC ([TableName], RESEED, [NumberYouWantToStartAt])

Это конечно безумие ... и никогда не должно быть сделано :)

MySQL не будет повторно использовать идентификаторы, пока вы не урежете таблицу или не удалите из таблицу без условия where (в этом случае MySQL внутренне просто выполняет усечение ).

Не специально. Если ключ читается из последовательности или столбца идентификаторов с автоинкрементом, последовательность просто подключится и выдаст следующее значение. Однако вы можете деактивировать это ( установить identity_insert в на SQL Server) и поместить любое нужное число в столбец, если это не нарушает ограничение уникальности.

Да, это действительно зависит от того, как вы генерируете идентификатор.

Например, если вы используете GUID в качестве первичного ключа, большинство реализаций получения случайного нового Guid вряд ли снова выберут другой guid, но ему будет достаточно времени, и если Guid нет в таблице, вставка оператор пойдет хорошо, но если там уже есть guid, вы получите нарушение ограничения первичного ключа.

Я считаю MySQL " функцией " повторного использования идентификатора это ошибка.

Рассмотрим что-то похожее на обработку загрузки файлов. Хорошей практикой является использование идентификатора базы данных в качестве имени файла: просто, нет риска эксплойтов с предоставленными пользователем именами файлов и т. Д.

Вы не можете сделать все транзакции, когда задействована файловая система ... вам придется зафиксировать транзакцию базы данных, затем записать файл или записать файл и зафиксировать транзакцию базы данных, но если одна или обе не удаются, или у вас происходит сбой, или ваша сетевая файловая система соответствует, возможно, у вас есть действительная запись в базе данных и нет файла, или файл без записи в базе данных, поскольку эта вещь не является атомарной.

Если такая проблема возникает, и первое, что сервер делает при возврате, перезаписывает идентификаторы и, следовательно, файлы откатанных транзакций, это отстой. Эти файлы могли быть полезны.

нет, представьте, если ваш банк решил повторно использовать ваш account_id - arghhhh !!

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top