Тут зависит от того для кого вы пишите проект, возможно и софт делит не нужен, и даже транзакции можно удалять) Но тут нужно так сказать знать грань.

это до тех пор пока кто-то не докажет обратное)

как с телефонами

раньше было ок, а теперь это ПД

по поводу soft delete старая презентация (кусок касающийся soft delete) http://ocramius.github.io/doctrine-best-practices/#/73

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

Всё верно, но не относится к нормализованным реляционным базам. Для key-value eventually consistent систем, действительно, можно удалять что угодно без проблем - софт всегда умеет обрабатывать отсутствие данных

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

это говорит что можно жить без soft delete но надо четко понимать где твои релейшены и при удаление что с ними может быть, если речь о реляционных бд помимо onDelete cascade есть и другие варианты (set null например)

но это опять же гадание на кофейной гуше

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

у Клепмана в Высоконагруженных БД это написано, если кому то нужны референсы на умных челов

условно нам может быть нужно поле deletedBy или createdBy, но не нужно знать о состоянии в момент создания или удаления

все что можно заключить про софт делит и прочие поля аудита это то, что если нужно что-то больше чем это, то нужно что-то большее чем нормализованная реляционная бд

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

soft delete обычно скрывает другие проблемы данных которые пытаются решить через soft delete с различным успехом ...

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

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

ну если для аналитика нужно
значит возможно не стоит это удалять
и мысль идет что путают удаление с архивирование (скрытием) записи ?
об этом первое сообщение после вопроса было что не путают ли удаление со снятием с витрины и тд

архивирование это перенос данных, софт делит это метка на полях "только для внутренних нужд"

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

ну это понятно) однако стоит учитывать что то что сегодня можно удалить, завтра может понадобится) и я бы сказал что все сущности в бд должны быть софт, если не предпологается иное

мы идем к write only
потом задаемся что редатирование это тоже не перезапись колонки
er но он нужен далеко не всем