Если вы будете единственным разработчиком ПО я рекомендую не выбирать путь с триггерами и реализации логики на стороне БД. Так как проблем создадите себе много а плюсы этого метода — не прочувствуете.
Разработка всей или части логики на стороне БД удобна в случаях когда нужно 'разделять и властвовать', когда удобно, из соображений надежности разработки и минимизации ошибок (например нарушений логической структуры БД), выделить и оформить соответствующий код на стороне БД таким образом, чтобы логику структуры БД невозможно было нарушить никакими ошибками на стороне приложения (php/java/..). Собственно изначально за кодом на стороне БД эта функция и закреплялась — контроль над целостностью БД.
Просто зачастую не так просто выделить часть логики, которую можно 'красиво' реализовать именно на тригерах и хранимых процедурах. К примеру все что касается интерфейса (или форматов запросов API) глупо реализовывать на хранимых процедурах, а вот методы, к примеру реализующие операции со счетами пользователей (такие как транзакции перевода между пользователями), лучше реализовывать внутри БД в виде хранимой процедуры.
Ну и конечно, у серверных приложений доступно на выбор огромное количество уже готовых решений, библиотек, фреймворков… которых может просто не оказаться для языка хранимых процедур вашей БД.