Users::where('created_at', '>', Carbon::now()->subHours(24))
->select('login')->groupBy('login')->orderBy(DB::raw('count(*) desc'))->get();<br>
UPDATE fine SET sum_fine = sum_fine * 2 <br>
From (SELECT name, number_plate, violation<br>
FROM fine<br>
GROUP BY name, number_plate, violation<br>
HAVING count(*) > 1<br>
) query_in<br>
WHERE fine.name = query_in.name AND fine.number_plate = query_in.number_plate AND fine.violation = query_in.violation AND fine.date_payment IS NULL;количество логики, которое впихивают в БД может быть разным и где-то стоит провести границу. А вот где - ворос дискуссионный и однозначного ответа не имеет.
Я имел в виду, что трггеры, особенно триггеры с тяжелыми проверками, влияют на производительность. Триггер срабатывает на изменение всей заиси, а факт изменения отдельных полей нужно детектить внутри триггера. Но мы же можем захотитеть делать более сложные валидации внутри БД, и нам для этого захоется внутри триггера делать SQL-запросы, обращаться к каким-то внешним настройкам, а эти настройки могут вдруг поменяться..
А ещё мы можем захотеть детектить на уровне БД наличие похожих по написанию букв на разных языках. К примеру, русская фамилия с английской буквы "A" будет ломать сортировку, а выглядеть корректно. Место ли для такой валидации на уровне БД? А проверка адекватности даты рождения?
Если мы говорим о том. что у нас большой проект и много неопытных чижиков без налаженного ревью кода, то косяк в валидации ввода на бэке попортит новые записи, а косяк в изменении правил валидации на уровне БД может обрушить всю базу.
Я конечно сгущаю краски немного, но если некоторые валидации делать не в БД, то эта лестница будет на ступеньку меньше.
До первой встречи с ситуацией когда у вас огромная бд заполнена каким нибудь трешом, и из-за этого встало поступление бабла в контору.
"БД как бастион" - это не близкая мне концепция. Я склоняюсь к простоте, всяким NoSQL, и чтоб не упарываться сильно с нормализацией данных без острой на то нужды и необходимости.
Я склоняюсь к простоте, всяким NoSQL