Видео

Добро пожаловать в современный ИТ. 1 инженер на 15 долбо... будущих менеджеров.

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

Согласен

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

@@lostinthewhitesea не важно для кого конфа. Спикер читает по методичке евангелистов микросервисов, которая давно устарела (и все поняли, что она во многом врет). При этом монолит рассматривается как нечто мертвое как концепция и не понимает, что он тоже может горизонтально масштабироваться.

Опенсорс база данных

Короче её не надо покупать? Надо свои бд из столбчатых в строковые перевести или начать строить?

@@pucyhok покупать не надо, можно из своих БД закинуть данные в Clickhouse

@@pucyhok Гугл и чатгпт в бане

Вчера райзнули до 700к на руки. Вот и веселый.

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

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

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

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

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

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

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

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

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

@@peteribragimov5071 Так у вас есть FK для проверки, ну то есть звучит в докладе как - мы просто напишем свой 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, потому что они "медленные" или "устаревшие".