количество логики, которое впихивают в БД может быть разным и где-то стоит провести границу. А вот где - ворос дискуссионный и однозначного ответа не имеет.
Я имел в виду, что трггеры, особенно триггеры с тяжелыми проверками, влияют на производительность. Триггер срабатывает на изменение всей заиси, а факт изменения отдельных полей нужно детектить внутри триггера. Но мы же можем захотитеть делать более сложные валидации внутри БД, и нам для этого захоется внутри триггера делать SQL-запросы, обращаться к каким-то внешним настройкам, а эти настройки могут вдруг поменяться..
А ещё мы можем захотеть детектить на уровне БД наличие похожих по написанию букв на разных языках. К примеру, русская фамилия с английской буквы "A" будет ломать сортировку, а выглядеть корректно. Место ли для такой валидации на уровне БД? А проверка адекватности даты рождения?
Если мы говорим о том. что у нас большой проект и много неопытных чижиков без налаженного ревью кода, то косяк в валидации ввода на бэке попортит новые записи, а косяк в изменении правил валидации на уровне БД может обрушить всю базу.
Я конечно сгущаю краски немного, но если некоторые валидации делать не в БД, то эта лестница будет на ступеньку меньше.
До первой встречи с ситуацией когда у вас огромная бд заполнена каким нибудь трешом, и из-за этого встало поступление бабла в контору.
"БД как бастион" - это не близкая мне концепция. Я склоняюсь к простоте, всяким NoSQL, и чтоб не упарываться сильно с нормализацией данных без острой на то нужды и необходимости.
Я склоняюсь к простоте, всяким NoSQL
Есть тенженция делать БД как можно тоньше и не хранить в ней логику. Только данные.
Если валидацию сделать при вводе от пользователя, то внутри системы уже будут априори валидные значения. Одна проверка на входе и больше не проверем введенные данные никогда. Если сделать проверку по апдейту\инсерту записи в БД, то проверка будет делаться при каждом апдейте записи.
- логика должна лежать внутри репозитория с исходным кодом и не должна бэкапиться вместе с данными, а с тригерами это так не работает.
- производительность
- скрытая логика в неочевидном месте - это плохо.
- логика, размазанная по куче мест - это плохо. Всю необходимую валидацию в БД не сделать, а в бэкенде можно.Ну смутно могу представить что бы я не смог сделать в БД предоставленными инструментами. Как бы СУБД живут уже не один 10 лет, и чего только от них не требовалось за их жизнь.