Числовые первичные ключи удаленных записей в базе данных снова используются для будущих новых записей?
Это должно работать OOTB, вам нужно загрузить зависимости.
Кнопки предоставляют типы кнопок, которые будут автоматически определять, следует ли использовать HTML5 или Flash на основе функциональности браузера, и настоятельно рекомендуется использовать эти типы кнопок для определенных типов кнопок HTML5 или Flash. Это: копия, CSV, Excel, PDF.
В этом примере показаны эти четыре типа кнопок плюс печать, используемые со всеми необходимыми загружаемыми зависимостями.
blockquote>$(document).ready(function() { $('#example').DataTable( { dom: 'Bfrtip', buttons: [ 'copy', 'csv', 'excel', 'pdf', 'print' ] } ); } );Пожалуйста, обратитесь к:
https://datatables.net/extensions/buttons/examples/initialisation/export.html [112 ] https://datatables.net/extensions/buttons/
10 ответов
НЕТ. числовые первичные ключи не будут снова использованный, кроме Вас указывают их вручную (необходимо действительно избежать этого!)
AFAIK, это могло произойти в MySQL:
Как работы обработки AUTO_INCREMENT в InnoDB:
InnoDB использует автоинкрементный счетчик в оперативной памяти пока выполнения сервера. Когда сервер остановлен и перезапущен, InnoDB повторно инициализирует счетчик для каждой таблицы для первой ВСТАВКИ к таблице, как описано ранее.
Предложенное исправление: таблица innodb не должна терять след следующего числа для auto_increment столбца после перезапуска.
Зависит от системы автоматической нумерации. При использовании последовательности какого-либо вида числа удаленных записей не будут снова использованы, поскольку последовательность не знает о них.
Обычно не числа не снова используются.
Однако Вы можете - в продуктах как Oracle - указывают генератор последовательности, какие циклы вокруг и снова использует числа.
Является ли это числами удаленных записей, или не проблема Ваших приложений.
Этот вопрос должен быть сделан более точным:
... "с последовательностями Oracle"
... "с MySQL автоматически нумеруют столбцы"
... и т.д...
MySQL не снова использует идентификаторы если Вы truncate таблица или delete from таблица без where пункт (в этом случае MySQL, внутренне, просто делает a truncate).
Пока Вы составляете таблицу правильно, Вы не снова используете числа. Однако можно ПЕРЕСЕЯТЬ столбец идентификационных данных (В MSSQL так или иначе) при помощи следующего:
- Введите номер последнего действительного доступа в таблице не следующее число, которое будет использоваться
DBCC CHECKIDENT ([имя таблицы], ПЕРЕСЕЙТЕ, [NumberYouWantToStartAt]),
Это, конечно, безумно... и никогда не должно делаться :)
Не конкретно. Если ключ будет считан из последовательности или автоувеличивающей столбец идентификационных данных, то последовательность просто включится вперед и произведет следующее значение. Однако можно деактивировать это (set identity_insert on на SQL Server) и помещенный любое число Вы хотите в столбце, пока это не нарушает ограничение уникальности.
Да, это действительно зависит от способа, которым Вы генерируете идентификатор.
Например, если Вы будете использовать GUID в качестве первичного ключа, то большинство реализаций получения случайного нового Гуида вряд ли выберет другой гуид снова, но это будет, учитывая достаточное количество времени и если Гуид не будет в таблице, то оператор вставки пойдет прекрасный, но если уже будет гуид там, то Вы получите ограничительное нарушение первичного ключа.
Я считаю "особенность" MySQL повторного использования идентификатора ошибкой.
Рассмотрим что-то вроде обработки загрузки файлов. Использование идентификатора базы данных в качестве имени файла является хорошей практикой: просто, без риска взлома с пользовательскими именами файлов и т. Д.
Вы не можете сделать все транзакционным, когда задействована файловая система ... вам придется зафиксировать транзакцию базы данных, затем записать файл или записать файл и зафиксировать транзакцию базы данных, но если один или оба из них не работают, или у вас есть сбой, или ваша сетевая файловая система подходит, у вас может быть действительная запись в базе данных и нет файла или файла без записи в базе данных, поскольку это не атомарно.
Если возникает такая проблема, и первое, что сервер делает, возвращаясь, это перезаписывает идентификаторы и, следовательно, файлы отката. транзакции, это отстой. Эти файлы могли быть полезны.