Moving some of the application logic to triggers is not a bad idea but the question is what database are you using? Triggers in MySQL are poorly done yet so I find it a bit clumsy to program and use them. Also, many shared hosts don't allow triggers so if you want your code to be portable then it's not a good idea. Another thing to consider is server load - quite often the database is the part that eats up most of the resources so in that case it's a good idea to do as much logic in PHP as possible to offload the db - but this might not be a problem in your case.
I think moving a lot of the business logic to triggers and stored procedures is most useful in cases where multiple clients (possibly working in different environments/languages) connect to the db so all your important stuff is centralized. In case of most PHP applications you have only one client - PHP - so this point is not really that important.
Generally, MySQL's SQL is a pretty basic language compared to PHP so at times you may run into limitations which will make it much harder to do the stuff you want in triggers or stored procedures. If I were to go that route I'd choose a more advanced db and preferably also have the ability to write stored procedures in languages other than SQL for best flexibility and performance. But for general work in PHP + MySQL I stay away from triggers, keep most of my code in PHP and occasionally I use stored functions, procedures and views for simple stuff that the db is well suited for.