Стратегия для решения проблемы с идентификацией базы данных/аутономемкой maxing out

Question

Поля ввода-вывода (например, «идентификация» в SQL Server) являются распространенным методом предоставления уникального ключа для таблицы базы данных. Однако, учитывая, что они довольно распространены, в какой-то момент в будущем мы будем иметь дело с проблемой, когда они начнут достигать своего максимального значения.

Кто-нибудь знает или имеет рекомендованную стратегию, чтобы избежать этого сценария? Я ожидаю, что многие ответы будут предлагать переход на гиды, но учитывая, что это потребует большого объема разработки (особенно когда многие системы интегрированы и разделяют ценность), есть ли другой способ? Мы движемся в направлении, где новые аппаратные/операционные системы/базы данных просто позволят увеличить и увеличить значения для целых чисел?

Answer 1

Если вы действительно ожидали, что ваши идентификаторы закончились, используйте bigint. Для большинства практических целей это никогда не закончится, и если это произойдет, вы, вероятно, должны использовать uniqueidentifier.

Если у вас есть (это означает, что транзакции/цикл на процессоре 3.0GHz) транзакций в секунду, это займет около столетия для bigint выбежать (даже если вы отложили немного для знак).

Это сказал однажды, «640K ought to be enough for anybody.» :)

Answer 2

Есть возможность перебрать номера, которые были удалены из базы данных? Или большинство записей все еще живы? Просто мысль.

Моя другая идея была предложение Мердад о переходе на BigInt

Answer 3

См эти вопросы, связанные с:

• Reset primary key (int as identity)
• Is bigint large enough for an event log table?

Принятая/топ проголосовавшие ответы в значительной степени покрыть ее ,

Answer 4

Идентификационные столбцы, как правило, начинаются с 1 и увеличиваются на +1. Отрицательные значения столь же верны, как и положительные, что удваивает пул доступных идентификаторов.

Answer 5

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

Для таких случаев и для случаев, когда вы хотите избежать наличия «допустимых» идентификаторов (веб-приложений и т. Д.), Я бы предложил использовать Гиды (Uniqueidentifiers) со значением по умолчанию нового Guid в качестве замены столбцов идентификации.

Поскольку Гиды уникальны, они позволяют синхронизировать данные должным образом, даже если записи были добавлены одновременно с системой.