Для решения такой задачи нужно просто в соответствующие таблицы добавить поле [Deleted] bit. И триггер:
Create trigger ttt on MyTable
for DELETE
as -- Заменяет физическое удаление на логическое
insert into MyTable
select Fld1, Fld2, Fld3, 1 -- 1 должна попасть в поле [Deleted]
from Deleted

И View:
select Fld1, Fld2, Fld3 from MyTable where [Deleted]<>1

И всё! Вместо того, чтобы давать прямой доступ к таблицам, работай со View. Восстановление удаленной записи сводится к сбросу флага [Deleted].
В этот же триггер можно воткнуть регистрацию, когда кем удалена и с какого компьютера. У меня работает еще сложнее. Регистрируются любые модификации данных. Журнал ведется в самой исходной таблице. Отслеживается история изменений одной и той же записи независимо :
- по оси календарного времени
- по оси учетного времени
все модификации производятся добавлением новых версий записей (с помощью Instead-триггеров). Вместо одного идентификатора используется несколько (идентификатор записи как совокупности всех редакций на всех осях, идентификатор редакции на оси учетного времени, идентификатор редакции на оси календарного времени). Конфликты репликации отсутствуют непрочь. Не смотря на то, что MERGE-репликация задействуется по схеме приоритетов, во VIEW выбор идет по календарной дате последней модификации. Поэтому наряду с журнализацией решается проблема устранения несогласованности транзакций при MERGE-репликации.