Why foreign keys are Evil. Append-Only and Soft-Delete - Peter Ibragimov | ITAM: BACKEND MEETUP 

По ФЗ-152, GDPR и тд можно просто анонизировать имя, почту и телефон. ВСЁ. Вы не обязаны удалять историю платежей, историю покупок и все остальное

Я даже больше скажу. В РФ, да и в других странах, правоохранительные органы/менты часто просят дать информацию по тем или иным пользователям, даже если они удалились

@@peteribragimov5071 понял принял

Обычно данные анонимизируют, а не удаляют. Так как в противном случае данные станут несогласованными в связанных таблицах. А удалять их еще и в связанных таблицах может быть весьма проблематичным. Например, эти данные могут участвовать в отчете по кассе или еще где-то. То есть такие данные мы просто не можем удалить. И тогда что делать? Просто глупо заводить какую-то анонимную запись и заменять на её идентификатор во всех таблицах. Значительно проще просто обновить персональные данные пользователя (клиента), затерев их каким-то специальным набором символов, шаблоном и так далее.

@@user-mz6xs3eq7w в таком случае главно понимать, что одним изменением таблицы users/accounts можно не обойтись, клиент мог "наследить" своими данными где угодно, например в чате с поддержкой и тд. Получается, что потребуется точно такая же процедура как по удалению, найти все активности юзера и затереть.

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

FK замедляют работу СУБД, при этом гарантируют консистентность только в том случае, если кто-то залезает в базу и нарушает консистеность, либо не проверяет ее вручную на беке (что и так делать надо)

@@peteribragimov5071 а проверка вручную не замедляет работу? если вы пытаетесь влепить id пользователя которого нет, то без связи по ключам перед вставкой нужно делать выборку что займет больше времени. вообще в таких спичах нужны замеры, тем более что товарищ озвучил разные субд...

@@peteribragimov5071 то что делать проверки на бэке надо, это понятно. Но здесь у тебя есть хотя бы запасной парашют ввиде БД, а тут получается ты сам, без страховки. Как по мне, риск появления неконсистентного стейта в системе на порядки выше. В команде работают люди разной компетенции, хотя и синьоры много ошибаются. Эту идею можно развить, сказав, что и тесты тоже зло и не нужны, ведь они так же не гарантируют отсутствие багов.

@@peteribragimov5071 бэкендов много, в базу лезут и вручную, данные подкачиваются со сторонних источников. Проверить целостность данных на беке можно только лишь выкачав из базы связанные данные, что излишне. Зачем изобретать велосипед у себя в бэкенде, если согласованность данных можно обеспечить за счет готового универсального решения?

@@peteribragimov5071 Так у вас есть FK для проверки, ну то есть звучит в докладе как - мы просто напишем свой FK (реализуем все проверки которые он делает) и будем иметь больше гибкости так как это наше решение. Возможно в каких-то исключительных случаях написание кастомных проверок на беке вместо использования готового решения и норм, но в общем случае лучше использовать уже готовое универсальное решение поставляемое БД

1. Если кто-то залезает в БД руками - эти руки надо оторвать:). 2. Нарушить консистентность бизнес-процессов через обход бекенд можно вне зависимости от того, есть FK или нет. Скажем можно зайти в БД и понизить стоимость заказа. Или, например, накинуть себе баланса. 3. Проверять корректность инпутов в любом случае надо. Если, скажем, мы создаем заказ на 100 человек на 1000 позиций, то нам в любом случае надо проверить, что все эти 100 человек есть, они имеют право получить заказать указанные товары и тд. При этом менять айдишники - плохая практика, поэтому мы можем быть уверены, что значения будут корректными

@@peteribragimov5071 1. В базу лезут все всегда. Даже те кто обещает, что не залезет. Это просто факт, с которым надо смириться и учитывать. Ну конечно в финтехе каком-нибудь с этим построже, но в большенстве компаний думаю всем насрать. 2. Да, можно, но это не повод давать еще больше возможностей все сломать. 3. Проверять то нужно и все проверяют весь ввод пользователя и все такое. Но вот скрипты, которые запускаются по крону и делают сложные штуки не будут проверять так как это долго. Какая нибудь статистика не будет проверять. Какая-нибудь джоба чтобы быстрее выполниться не будет проверять. Какой-нибудь джун накосячит. Сам случайно накосячишь. А потом в коде вызываешь order->user->id и получаешь в лоб исключение, что юзера нет)

@@peteribragimov5071 1. В базу лезут все всегда. Даже те кто обещает, что не залезет. Это просто факт, с которым надо смириться и учитывать. Ну конечно в финтехе каком-нибудь с этим построже, но в большенстве компаний думаю всем насрать. 2. Да, можно, но это не повод давать еще больше возможностей все сломать. 3. Проверять то нужно и все проверяют весь ввод пользователя и все такое. Но вот скрипты, которые запускаются по крону и делают сложные штуки не будут проверять так как это долго. Какая нибудь статистика не будет проверять. Какая-нибудь джоба чтобы быстрее выполниться не будет проверять. Какой-нибудь джун накосячит. Сам случайно накосячишь. А потом в коде вызываешь order->user->id и получаешь в лоб исключение, что юзера нет)

@@peteribragimov5071 если в бд через триггеры везде стоят запреты, то фиг ты поменяешь стоимость заказа. Если достаточно плотно обложить всё ограничениями и проверками, то испортить данные можно будет только имея высокие привилегии в бд.

@@peteribragimov5071 Отрывание рук никак не поможет решит уже существующую проблему с удалёнными данными. Нужно максимально заботиться о целостности данных. Всегда. Наивно думать, что никто не сделает "плохо" или "неправильно". Обязательно сделает. И вы потеряете данные. А вот кому после этого руки отрывать - это тоже вопрос. Возможно тем, кто отказывается от fk, потому что они "медленные" или "устаревшие".