hVosttIsDeleted натуральное зло, тупейший костыль, которым грешат нубасы.

а что не зло? как делают не нубасы?

hVosttlove_bachпропущено...


а что не зло? как делают не нубасы?

Операция «Удаление» это удаление, оно должно приводить к удалению данных из системы. Что должен понять сотрудник глядя на запись с IsDeleted == true? Это что вообще значит? Случайно создали кривую запись и грохнули? Объект выведен из эксплуатации? Ошибка тёти Маши? Как это вообще отвечает целостности, за которую так божатся, выбирая SQL? Если записи нет, на неё сослаться нельзя, буквально физически, сервер не даст с констрейтами.

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

Потом. Писать запросы с учётом IsDeleted, строить отчёты, проводить какую-то аналитику, становится дорогим и затратным делом. Всё равно, что лазить в холодильник и выбирать какая колбаса свежая, из всего мусора, который там навален. И наклеечки «пропало» не улучшают ситуацию.

Но всё равно так делают. Много и часто. И не от большого ума, скорее прикрыть точку, ну и от бездарности и лени (не той, что делает разработчика профессионалом, а другой консистенции).

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

love_bachhVosttпропущено...


Операция «Удаление» это удаление, оно должно приводить к удалению данных из системы. Что должен понять сотрудник глядя на запись с IsDeleted == true? Это что вообще значит? Случайно создали кривую запись и грохнули? Объект выведен из эксплуатации? Ошибка тёти Маши? Как это вообще отвечает целостности, за которую так божатся, выбирая SQL? Если записи нет, на неё сослаться нельзя, буквально физически, сервер не даст с констрейтами.

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

Потом. Писать запросы с учётом IsDeleted, строить отчёты, проводить какую-то аналитику, становится дорогим и затратным делом. Всё равно, что лазить в холодильник и выбирать какая колбаса свежая, из всего мусора, который там навален. И наклеечки «пропало» не улучшают ситуацию.

Но всё равно так делают. Много и часто. И не от большого ума, скорее прикрыть точку, ну и от бездарности и лени (не той, что делает разработчика профессионалом, а другой консистенции).

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

я, например, пришел к выводу, что такие "IsDeleted" - это фактически требование наличия лога, отличного от основной структуры БД