Avoid Soft-Deletes

Вот тут (любопытные слайды от Marco Pivetta) утверждают, что Soft Deletes - это "broken idea" и она "come from an era where keeping everything in a single DB was required". Я как-то не задумывался об этом никогда и использую постоянно. В принципе и реализуется оно достаточно прозрачно хоть с мапперами, хоть в AR, как мне казалось.
Хотелось бы услышать мнения на этот счёт. А главное, там тема подробно не раскрыта и если этот подход устарел, то что актуально на данный момент и как реализуется/применяется? Возможно ссылки на статьи или примеры?

Использую на основном проекте. Физически данных не удаляем, типа профиля пользователя и т.д. Только ставим флажок - deleted. Избавляет от гемора с связанными данными, а их у нас очень много =\

@Sufir, видел данный подход в SugarCRM последних версий.
Прикольная штука, у них реализовано так, что если удаляешь запись - ставится флаг удален.
А крон каждый день такие "удаленные" данные(если после удаления прошло n дней) уже реально удаляет и удаленные данные записывает в специальную папку в текстовом виде.
Я был в восторге от их идеи... Минусов реально не вижу.

По слайдам непонятно, в чем проблемы. Наверное, doctrine-специфика.

Вероятно, хотя и в doctrine можно вполне удобно и достаточно просто реализовать soft-delete без особых сложностей. Если в остальном всё понятно в слайдах, то этот момент меня смутил, в т.ч. "come from an era where keeping everything in a single DB was required", что как бы намекает, что этот подход в принципе устарел и имеются альтернативы.

Ну, он типа предлагает разруливать это состоянием на уровне domain model. Makes sense, если предполагается, что это относится к уровню domain model (скажем, есть штатная процедура восстановления). Если же не предполагается, и на уровне domain это именно удаление - не вижу проблем с софт делитами, это такой infrastructure/maintenance hack, из инфраструктуры никак не протекающий при правильной реализации. Причем тут single db, непонятно вообще, какая разница?

Вообще у него там много спорного, местами похоже на легкий mongodb головного мозга.

В node есть ORM sequelize, это AR, но за неимением лучшего использую именно ее. В ней концепция soft deletes встроенна повсеместно.
То есть если для сущности включить soft delete, то вызов метода destroy просто вставит дату в deleted_at, все запросы прямо внутри ON джойна будут учитывать deleted_at.
Так что это скорее проблема исключительно доктрины. У нее вообще туча проблем, начиная от высокой, не оправданной сложности кода, заканчивая решением всех проблем кешированием где только можно. Но это мнение могло устареть на год - полгода.

А он вместо soft delete предлагает immutable? То есть только insert, никаких update, delete? На сколько я знаю это тоже подход, где-то он оправдан, а где-то нет. Так что странно развешивать ярлыки.

В node есть ORM sequelize, это AR, но за неимением лучшего использую именно ее

Нажмите для раскрытия...

bookshelf еще есть, мне показался вменяемее, DDL на уровне модели - какое-то совсем злое зло

fixxxer написал(а):

bookshelf еще есть, мне показался вменяемее, DDL на уровне модели - какое-то совсем злое зло

Нажмите для раскрытия...

ты код почитай. Когда я смотрел, там модели из backbone использовали для собственно моделей и коллекции для коллекций. Мне такой подход не сильно понравился.
DDL - это ты про что конкретно? Он там через всю ORM тоже протянут. Например вместо привычного квери-билдера там чем-то похожая на монгу конфигурация. Вроде
Но с этим можно более-менее жить.

hell0w0rd написал(а):

ты код почитай

Нажмите для раскрытия...

по крайней мере, квери билдер там вменяемый, из этого можно при желании сделать нормальный dm

это ты про что конкретно

Нажмите для раскрытия...

про sync()

Sufir написал(а):

Вот тут (любопытные слайды от Marco Pivetta) утверждают, что Soft Deletes - это "broken idea"

Нажмите для раскрытия...

Какие альтернативы? Не удалять вообще?…

если история нужна, insert select; delete; а так просто delete, ну те. проблем больше если удалил навсегда а через пол года инвойс нужно напечатать.

Не, инвойс и прочая бухгалтерия - там всё понятно, это вообще не удаляется, ни софт, ни как.

Да знаешь, на каждом уровне одинакого, для кого и удалить сообщение может быть роковым