Например, если у меня есть поле с пронумерованным номером, я добавляю новые записи, не указав это поле, и пусть механизм БД выбирает его для меня.
Итак, будет ли он выбирать номер удаленной записи? Если да, то когда?Нужно ли использовать числовые первичные ключи удаленных записей в базе данных для будущих новых записей?
// SQL Server, MySQL. //
последующий вопрос: What happens when DB engine runs out of numbers to use for primary keys?
NO. числовые первичные ключи не будут повторно использоваться, за исключением того, что вы укажете их вручную (вы действительно должны этого избегать!)
Зависит от системы автоматической нумерации. Если вы используете последовательность любого типа, номера удаленных записей не будут использоваться повторно, поскольку последовательность не знает о них.
Как правило, нет, цифры не используются повторно.
Однако вы можете - в таких продуктах, как Oracle, - указать генератор последовательности, который циклически перемещается и будет повторно использовать числа.
Независимо от того, являются ли эти номера удаленных записей или нет, это проблема ваших приложений.
Не конкретно. Если ключ считывается из последовательности или автоинкрементного столбца идентификации, последовательность просто подключается и создает следующее значение. Однако вы можете деактивировать это (set identity_insert on на SQL Server) и поместить любой номер в столбце, если он не нарушает ограничение уникальности.
+1 с незначительной коррекцией/предостережением для SQL Server - для вставки значения в столбец идентификатора, SET IDENTITY_INSERT ON должен быть указан до того, как будет вставлено явное значение идентификации (см. http://msdn.microsoft.com/en-us/library/ms188059.aspx). – 2008-10-31 14:11:28
Спасибо. Хорошо подмечено. – ConcernedOfTunbridgeWells 2008-10-31 20:08:30
Этот вопрос должен быть более точным:
... "с Oracle последовательностях"
... "с MySQL Autonumber столбцы"
... и т.д. ...
Я указал два двигателя, которые меня интересуют. – 2008-10-31 13:55:18
Пока вы правильно создаете таблицу, вы не будете повторно использовать числа. Однако вы можете повторно заполнить столбец идентификаторов (IN MSSQL в любом случае), используя следующее:
- Введите номер последней действительной записи в таблице не следующий номер будет использоваться
DBCC CHECKIDENT ([ TableName], переустановка, [NumberYouWantToStartAt])
Это, конечно, безумного ... и никогда не должно быть сделано :)
MySQL не будет повторно использовать идентификаторы, если вы truncate таблицы или delete from за стол, не where статьи (в этом случае MySQL, внутренний ly, просто делает truncate).
AFAIK, это может произойти в MySQL:
How AUTO_INCREMENT Handling Works in InnoDB:
InnoDB использует в памяти автоинкрементируемого счетчик до тех пор, как работает сервер. Когда сервер останавливается и перезапускается, InnoDB повторно инициализирует счетчик для каждой таблицы для первого INSERT для таблицы, как описано выше.
After a restart of server. Innodb reuse previously generated auto_increment values. :
Похожие фикс: InnoDB таблицы не должны потерять след следующего номера для столбца AUTO_INCREMENT после перезагрузки.
Да, это действительно зависит от способа генерации идентификатора.
Например, если вы используете GUID в качестве первичного ключа, большинство реализаций получения случайного нового Guid вряд ли снова выберут другое руководство, но оно даст достаточно времени, и если Guid не находится в таблице, инструкция insert будет хорошо, но если там уже есть указатель, вы получите нарушение ограничения первичного ключа.
Я рассматриваю MySQL «функцию» повторного использования идентификатора id.
Рассмотрите что-то вроде обработки загрузки файлов. Использование идентификатора базы данных в качестве имени файла является хорошей практикой: простой, без риска эксплойтов с предоставленными пользователем именами файлов и т. Д.
Вы не можете сделать все транзакционным, когда задействована файловая система ... у вас будет чтобы зафиксировать транзакцию базы данных, затем напишите файл или напишите файл и зафиксируйте транзакцию базы данных, но если один или оба сбой, или у вас произошел сбой, или ваша сетевая файловая система подойдет, у вас может быть действительная запись в базе данных и ни файл, ни файл без записи базы данных, поскольку вещь не является атомарной.
Если такая проблема возникает, и первое, что сервер делает при возвращении, перезаписывает идентификаторы и, следовательно, файлы, откат транзакций, это отстой. Эти файлы могли быть полезны.
нет, представьте, если ваш банк решил повторно использовать ваш account_id - arghhhh !!
См. Ответ от Martin Bøgelund. В некоторых случаях они используются повторно. – user984003 2013-02-07 15:27:38
Ответ Martins правильный, однако он связан с одним DB-движком и редкими обстоятельствами и, очевидно, является ошибкой (не знаю, планируют ли они это исправить) – 2013-02-08 10:16:42