"INSERT INTO plain(note) VALUES('first'),('second');"

"INSERT INTO historical(note) VALUES('first'),('second');"

"DELETE FROM plain WHERE id=2;DELETE FROM historical WHERE id=2;"

)

plain_id = connection.execute("INSERT INTO plain(note) VALUES('new')").lastrowid

historical_id = connection.execute("INSERT INTO historical(note) VALUES('new')").lastrowid

assert plain_id == 2

assert historical_id == 3

print(plain_id, historical_id)

connection.close()

В первом варианте свободный номер максимальной удалённой строки использован снова. Во втором показанный AUTOINCREMENT изменил правило автоматической выдачи. Это сравнение двух явно созданных учебных таблиц. Из результата не следует, что все обычные номера повторяются, или что автоматическая нумерация обязана идти без пропусков.

Что задать помощнику до приёмки

Спроси, где будет жить идентификатор: только внутри текущей таблицы или ещё во внешнем журнале с уже удалёнными объектами. Для второй задачи отдельно согласуй свойство отсутствия повторного использования. Затем проверь создание, удаление и новое создание. Выбор AUTOINCREMENT не нужно делать механически: у него есть дополнительные издержки, а постоянная идентичность между несколькими базами требует иных договорённостей.

Никакая рабочая база не открывалась; таблицы существовали только в памяти и соединение закрыто. Код не предлагается как миграция. Он проверяет автоматическую выдачу номера в конкретном простом сценарии, а не правила ручного задания ID, восстановления, распределённой генерации или отменённых транзакций.

Это учебный синтетический пример, подготовленный с помощью ИИ. Показанный код выполнен локально на вымышленных данных; реальные клиентские файлы и внешние сервисы не менялись.

Первоисточник: https://www.sqlite.org/autoinc.html

Разборы новостей и инструментов ИИ — в Jarvis News: https://t.me/jarvis_and_news

В каком мире живут эти люди? Что они пишут? Очнитесь, господа! 90% кода claude на данный момент пишет сам claude. Примерно такой же процент у новых коммитов в ядро линукса. Линус Торвальдс пишет с ИИ. Дядя Боб говорит: Моя нынешняя стратегия вообще не читать код, написанный моими агентами.

Что же за масштабные и сложные проекты пишут рандомные комментаторы с пикабу, что ИИ их не тянет😂. Страшно подумать.

(1, "2026-10-01T10:00:00"),

(2, "2026-10-01T10:00:00"),

(3, "2026-10-02T10:00:00"),

])

rows = db.execute(

"SELECT id FROM events ORDER BY created_at DESC, id DESC LIMIT 3"

).fetchall()

print(rows)

Результат:

[(3,), (2,), (1,)]

Мы явно договорились: при одинаковом времени первым идёт больший идентификатор. Уникальный id завершает порядок для этого набора. Это выбранное правило интерфейса, а не утверждение, что больший id всегда означает более позднее реальное событие.

Документация SQLite (https://www.sqlite.org/lang_select.html#orderby) не обещает определённый порядок строк, у которых равны все выражения ORDER BY. Если повторный запуск случайно показывает тот же порядок, это ещё не превращает наблюдение в гарантию.

Отдельная проблема — меняющиеся данные

Второй ключ помогает однозначно упорядочить текущий набор. Он не гарантирует отсутствие пропусков при перелистывании через OFFSET, если между запросами появляются или исчезают записи.

Для такого списка сначала выбирают требуемое поведение: нужен неизменный снимок, живая лента или продолжение после конкретной пары ключей. Это разные задачи. Не стоит обещать «исправленную пагинацию» после одного добавленного id.

В нашем примере все даты записаны в одном формате и предполагают одну временную шкалу. Разные часовые пояса и форматы нельзя незаметно смешивать в строковой сортировке.

Небольшая проверка перед выпуском

Создайте несколько строк с одинаковым основным ключом. Заранее задайте, какая должна идти первой. Проверьте результат целиком и на границе LIMIT. Затем отдельно рассмотрите вставку новой записи между запросами страниц.

Полезный вопрос к предложенному ИИ запросу: «Каким правилом разрешаются равные значения?» Если ответ — «база обычно возвращает так», правило пока не определено.

[(1, "open"), (2, "closed"), (3, None)])

simple = db.execute(

"SELECT id FROM tickets WHERE status != 'closed' ORDER BY id"

).fetchall()

explicit = db.execute(

"SELECT id FROM tickets "

"WHERE status != 'closed' OR status IS NULL ORDER BY id"

).fetchall()

print(simple)

print(explicit)

Результат:

[(1,)]

[(1,), (3,)]

`NULL` обозначает отсутствие значения. Сравнение `NULL != 'closed'` не становится истиной. Поэтому первая выборка не включает третью запись. Для явной проверки отсутствия значения служит `IS NULL`; это описано в документации SQLite (https://www.sqlite.org/lang_expr.html).

Какой запрос правильный

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

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

Не стоит заменять все NULL пустой строкой только ради красивой таблицы. После такой замены можно потерять различие между неизвестным значением и реально присланной пустой строкой. Здесь решение о хранении данных важнее краткости запроса.

Что передать ИИ до генерации SQL

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

Проверку сначала выполняют как SELECT на безопасной копии или синтетических данных. Успешная выборка ещё не является разрешением обновлять или удалять записи в рабочей базе. В показанном примере нет команды изменения настоящих заявок.