Реализация обратимого удаления с минимальным влиянием на производительность и код

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

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

Лично я бы основывал свой ответ на том, как часто вы ожидаете, что ваши пользователи захотят получить доступ к этим удаленным данным или «восстановить» эти удаленные данные.

Если это часто, то я бы использовал поле «Date_Deleted» и поместил вычисленное «IsDeleted» в свой poco в коде.

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

Лично я почти никогда не использую удаленные таблицы (и выбираю isDeleted или date_deleted) из-за потенциального риска для ссылочной целостности. У вас есть A -> B, и вы удаляете запись из базы данных B... Теперь вам нужно управлять ссылочной целостностью из-за вашего выбора дизайна.

На мой взгляд, лучший путь вперед, когда вы думаете о масштабировании и возможных размерах таблиц/баз данных, — это ваш третий вариант — отдельная таблица для удаленных элементов. Со временем такую ​​таблицу можно переместить в другую базу данных для поддержки масштабирования.

Я полагаю, что вы перечислили три наиболее распространенных варианта. Как вы видели, у каждого есть преимущества и недостатки. Лично мне нравится смотреть на вещи шире.

Предположим, мы создали поле с именем dead для отметки удаленных строк. Мы можем создать индекс, в котором поле dead ложно. Таким образом, мы ищем только неудаленные строки, используя индекс использования подсказки.

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

Использование одной таблицы с удаленным флагом. Если все ваши индексы сначала содержат поле удаленного флага, а ваш запрос в основном содержит структуру типа where isdeleted=false, то это ДЕЙСТВИТЕЛЬНО решает ваши проблемы с производительностью, а индексы очень эффективно исключают удаленные строки. Аналогичная логика может быть использована для опции удаленной даты.

Использование двух таблиц Как правило, вам необходимо внести значительные изменения в отчеты, поскольку некоторые отчеты могут ссылаться на удаленные данные (например, старые данные о продажах могут относиться к удаленной категории продаж). Это можно преодолеть, создав представление, которое представляет собой объединение двух таблиц для чтения и записи только в таблицу активных записей.