Переполнение столбца идентичности: когда это необходимо?

Во время одного из последних уроков в университете (я студент), лектор попросил нас разработать базу данных (MySQL Server, если это имеет значение) и крошечное клиентское приложение, которое будет использовать базу данных в качестве источника данных.

Одним из требований было то, что столбец идентификаторов (который является PK в каждой таблице) должен быть последовательным, потому что это хорошая практика (согласно словам лектора). То есть, когда строка таблицы удаляется, ее PK необходимо повторно использовать в последующих вставках. У меня есть средние знания в RDBMS, PK и столбцы идентичности. Из того, что я понимаю, этот столбец идентификаторов - это просто способ позволить БД автоматически генерировать PK при вставке строк и ничего более. И значение столбца идентичности никоим образом не должно быть связано с атрибутами строки (если это не естественный ключ).

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

Поэтому мне любопытно, реальны ли эти причины? Я могу думать только об одном случае, когда требуется повторное заполнение столбца идентификаторов - когда пространство идентификаторов исчерпано. Но это более сложная проблема, когда тип столбца идентификаторов был выбран неправильно, например, просто intвместо bigintили uniqueidentifierкогда таблица содержит миллиард строк. Предположим, столбец идентификаторов является кластеризованным индексом: могут ли пробелы в столбце идентификаторов влиять на производительность индекса? Может быть, существуют другие реальные причины автоматического повторного заполнения столбца идентификаторов после каждого удаления, о котором я не знаю?

Заранее спасибо!

То есть, когда строка таблицы удаляется, ее PK необходимо повторно использовать в последующих вставках.

Из какой вселенной твой лектор?

Это крайне неэффективно. Если вы попытаетесь сделать это, вы сократите свои перспективы производительности в 10 раз.

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

В MySQL InnoDB требует наличия уникального PRIMARY KEYдля каждой таблицы. Но это степень требования. Ключ даже может быть строкой.

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

Я могу вспомнить один случай, когда удобно использовать без промежутков - разбить на группы по 100 строк за раз. Но есть простой способ использования LIMIT 100,1.

Пробелы не влияют на производительность. Это включает нечисловые индексы. И неуникальные показатели. И составные показатели.

Конечно, вы можете исчерпать идентификаторы. Я думаю, я видел это дважды за почти два десятилетия использования MySQL. С таким же успехом я могу беспокоиться о том, что меня ударит астероид. Это низко в моем списке вещей, которые держат меня бодрствующими ночью.

Разрывы происходят из (по крайней мере): INSERT IGNORE, IODKU, REPLACE, DELETE, ROLLBACK(явное, или из - за аварии), Мульти-мастер репликации ( в том числе и Галера группы репликации). Вы действительно хотите придумать обходные пути для тех ?!

Не стесняйтесь просить нас о здравомыслии - проверяйте все остальное, что лектор считает подозрительным

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

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

Решение таких проблем может быть большой проблемой, когда компании объединяются или приобретаются. Создавать такие проблемы специально? Не мудрый.

Повторное использование значений идентификатора PK имеет проблемы и, как правило, его следует избегать.

Во-первых, реализация столбцов auto_increment не дает гарантии отсутствия пробелов. Действительно, пробелы возникнут, если вы откатите вставку в столбце автоинкремента.

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

В-третьих, bigint unsignedне хватит идентификаторов в течение значительного времени, даже если учесть чрезвычайно высокую скорость вставки.

Самая большая проблема с пробелами встречается с аудиторами, которые настаивают на недостатке аудита. Для администраторов баз данных они знают, что существуют пробелы и почему.

Я не буду повторять комментарии всех остальных о том, что повторное использование PK - плохая идея, но я сталкивался со случаями, когда столбец идентификаторов нужно было повторно заполнять.

Повреждение самого индекса PK.

Конечно, это было использование MS-SQL и много-много лет назад, но это все еще актуально. Много лет назад для компании, в которой я работаю, кто-то думал, что будет хорошей идеей повторно использовать ПК в качестве серверов в наших 150+ удаленных местах после того, как они станут слишком старыми для использования клиентами, а затем засунуть их в шкаф. без вентиляции. Когда нет Потому что все мы знаем, что куча ненужного 10-летнего компьютера в крошечной комнате со временами более 120 запущенных критически важных баз данных может привести только к хорошим вещам. Как 40% отказов и я переосмыслил свой выбор профессии. Мы будем копировать данные обратно в штаб-квартиру корпорации, но чаще всего эти сбои приводят к плохим вещам, происходящим с базами данных. Одной из таких вещей была база данных с поврежденными индексами, которые могли бы захватить базу данных и процесс репликации. Дважды в этой замечательной среде единственное решение для исправления репликации состояло в том, чтобы повторно заполнить индексы, а затем восстановить репликацию. Мы заменили серверы позже, перед тем как полностью отказаться от них.