@Boris007

Как обезопасить id SERIAL для корректной работы без промежутков значений?

Создал таблицу:

CREATE TABLE users(
   id SERIAL PRIMARY KEY,
   name VARCHAR(255)
)

При первых INSERT запросах было всё нормально, но потом после id == 9, следующий был id == 37, потом 81,82,83,84,85
Из-за чего это происходит и как этого избежать?
Как обезопасить записи в БД по их корректности?
  • Вопрос задан
  • 182 просмотра
Решения вопроса 3
@kalapanga
Прежде всего: https://www.postgresql.org/docs/current/datatype-n...
А здесь примеры есть: https://habr.com/ru/companies/tensor/articles/507688/
Если кратко, то это нормальное поведение.
Ответ написан
leahch
@leahch
3D специалист. Dолго, Dорого, Dерьмово.
Автоинкрементные ключи вообще лучше не использовать - это вселенское зло!
Используйте или uuid, или свой какой-то счетчик, или композинтый ключ или хеш, да все что угодно, только не автоинкремент.
Почему автоинкремент плохо - сотни статей в интернетах.
Вот на почитать;
- https://azimutt.app/blog/stop-using-auto-increment...
- https://www.clever-cloud.com/blog/engineering/2015...
Ответ написан
@Akina
Сетевой и системный админ, SQL-программист.
Примите постулат:

Никто не должен видеть значений автоинкрементного синтетического ключа, кроме самого сервера.

AI PK существует только и исключительно для правильной работы встроенной подсистемы СУБД, осуществляющей контроль целостности и непротиворечивости данных. Попытка возложить на такое поле ещё какую-то функцию, тем более функцию, в результате выполнения которой значения этого поля станут видны пользователю (ещё хуже - если эти значения станет необходимо видеть пользователю), немедленно порождает проблемы.
Причём порождаемые проблемы никак не связаны с основной функцией поля - вот какое пользователя собачье дело, последовательны значения или с разрывами? разрывы влияют на уникальность? нет... или они нарушают нормальную работу ссылочной целостности? нет... или они...? нет... А вся претензия в одном - типа "некрасиво". Аргумент для дураков - потому как значение в таблице БД, а некрасивость в выводе на экран, осуществляемом клиентским приложением. Но если даже отсутствие логики не препятствие, так вон тут рядом советовали - заводишь отдельное поле, в него "свой какой-то счётчик" программный, и поддерживай свою непрерывность хоть до посинения! тем более что сейчас найти (актуальную версию любой) СУБД, не поддерживающую CTE, ROW_NUMBER(), тем более ORDER BY - без шансов.
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы