Нужно пометить на удаление логически битовой маркой, а потом отправить в архив, где в процедурах на "гет" поставить is_del =false

у вас всегда секции "удачно" расположены?

Даже если у тебя полный мрак, удаление или искажение данных больший косяк, чем что угодно

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

Возьмём кейс с удалением страны/путевки

ок. и?

Ты удаляешь "не использующийся тур". Потом приходит бизнес и говорит "ой, а мы ошиблись". Что делаешь?

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

Не нашел про упоминание архивации в месте возникновения диалога

вы понимаете суть "архива" не архивирование сжатие, а архив, т.е. история

Я все прекрасно понимаю, кроме возникновения претензии к запрету на удаление данных

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

Вот создание таблицы:

       CREATE TABLE IF NOT EXISTS product_creation(
       user_id INT UNIQUE,
       category_id INT REFERENCES category(id),
       area_id INT REFERENCES area(id),
       coord_latitude DOUBLE NOT NULL,
       coord_longitude DOUBLE NOT NULL,
       photo_file_id INT,
       text VARCHAR(255)
       )


А вот создание записи

INSERT OR IGNORE INTO 
        product_creation(user_id)
        VALUES(23432432)

В итоге

Запрос успешно выполнен: INSERT OR IGNORE INTO 
        product_creation(user_id)
        VALUES(23432432) (заняло 0мс, 0 строк изменено)

Ничего не добавляет....

p.s. SQLite3

INSERT OR IGNORE INTO 
        product_creation(user_id)
        VALUES(23432432)

Запрос успешно выполнен: INSERT OR IGNORE INTO 
        product_creation(user_id)
        VALUES(23432432) (заняло 0мс, 0 строк изменено)

потому что 23432432 есть уже?

На самом деле была проблема, что два параметра NOT NULL. А OR IGNORE не показывало ошибку

а должно?

Нет как-раз
Из-за него сразу ошибку не увидела

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

Обратное действие тоже можно проделать.