Пришла тут такая идиотская мысль, если возможно - расскажите, в чем я не прав.
MSSQLSERVER 2019.
Есть некая БД, в форме "вывернутой" снежинки. Т. е., в центральной таблице - несколько десятков тысяч записей, в лучах - возможно, до пары, ну до пары десятков миллионов.
Причем на одну запись в центральной таблице приходятся минимум тысячи записей в дочерних и "внучатых" таблицах.
В дочерних и внучатых таблицах ключ центральной - присутствует (помимо ключа непосредственного мастера). И декларативная ссылочная целостность - тоже взведена (но без каскадных операций).
Связи между таблицами проиндексированы.

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

Сейчас перед вводом обновленных данных, пакет информации, ранее введенный клиентом - удаляется.
Но удаление явно является узким местом системы. Дает паразитную нагрузку на диск, конфликты блокировок, да и, собственно, блокировки при параллельной работе десятков клиентов, дедлоки, с которыми программисты героически борятся (но дедлоки ведут в счете) и т.д.

Собственно, пришла мысль - а не помечать ли просто родительскую запись в центральной таблице как удаленную, а видимостью (для бизнес-проверок) управлять через row level security?
А физически удалять данные - как нибудь потом, офшорно.
Эдакий - эрзац-постгресс, :-)
Сама база небольшая. Порядка 1 Гб за период. Ну, будет в период завала распухать на 100 Гб, да и шут с ней.
Как сильно снижение производительности при этом превысит плюсы решения?
Есть ли еще какие то подводные камни?
Может что-то еще посоветуете?

1 и 3 - уже давно сделано. О втором как раз и речь.
Проблема в том, что система а) унаследованная и б) она работает именно с загруженными в систему данными, и подразумевает, что нужные данные присутствует за период в единственном экземпляре. Т.е. расставить по таблицам флажок is_deleted - не получится, т.к. имеющаяся логика приложения о нем ничего не знает. При этом она еще и частично скрыта в сервере приложений.
Но, к счастью, логика работает от имени непревилегированного пользователя, не dbo, а имеющего только db_datareader и db_datawriter.
И, опять же, к счастью, удаление пакета - это одна хранимка, которая последовательно удаляет данные из тучи подчиненных таблиц. Другие "точечные" удаления в подчиненных таблицах - роли не играют.
Поэтому и появилась мысль - заменить процедуру удаления - простановкой флага в ОДНОЙ, центральной таблице, а всё остальное скрыть через row level security.
Изначально, года 4 назад, когда проблема начала донимать - хотели вообще заменить таблицы на вью с подобной же логикой, но не срослось, т.к. в сервере приложений какой то кусок считает, что имеет дело именно с таблицами (не знаю, как так можно написать было).
Но тогда всё решили как раз вылизыванием индексов, и покупкой пары SSD, ценой с Боинг.
И теперь мысль - пересадить всё на 2019, и решить как описано.
В чем может быть засада?

Что-то терзают меня смутные сомнения, что от этого будет какая то польза, кроме вреда.
Как минимум, потому что update ключа партиционирования - эквивалентно 2 операциям: удалению в одной секции и вставке в другой.
И, соответственно, куча индексов (которые действительно нужны), и которые придется выровнять - они тоже поедут в другую секцию, и т.д.
Т.е. вместо 1 операции физического удаления - 1 вставка, 1 удаление, и + truncate секции (интересно, как это будет работать от сотни коннектов параллельно).