Den is
А'ля ДБФ? Плюс - сомнительная ценность возможности восстановить запись. Часто проще ее снова занести.
Я уж не говорю, что удаление записей, которое нарушает целостность базы, должно быть запрещено.

Минус, как уже указал Estets - усложнение запросов.

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

Shtockтолько если нет специально обученной вьюхи "Актуальные записи".
Ну, допустим она есть. Снижается только сложность написания запросов, что совсем не критично, а вот сложность выполнения остается.
Вот нагородили - "case-средства", "партиционирование"... Лог изменеий вовсе не требует столь устрашающих терминов.

Den is.

Проектирование баз данных пока все-таки является искусством, а не технологией. Потому, что нет четких критериев, по которым можно определить, насколько эффективно будет то или иное решение. Вернее, критерии есть, но они будут доступны после того, как база отработает какой-то период времени. Заранее никто ничего определенно сказать не сможет.

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

Вы полагаете использовать механизм, который может восстановить нужное состояние базы после ошибочного удаления. Нормальное желание. Такой механизм будет работать, если не забывать про внутренние механизмы обеспечения целостности. Можно даже сделать так, что бы не сильно тормозило - создать соответсвующие индексы. Однако накладные расходы по созданию индексов могут оказаться слишком большими.

Вы забыли об ИЗМЕНЕНИИ. Да и о ВСТАВКЕ. На мой взгляд, о чем я кажется я уже писал в этом топике, в случае паталогической боязни потерять данные, лучше сделать логирование всех изменений в отдельные таблицы. Причем создание таких таблиц тоже может оказаться неприемлемым с точки зрения быстродействия.

Решать Вам.