Howto implement correctly Businness Logic in database
Best practice...

A database is a place to store data.  It is the 'source of truth'.

The application is the place for
* interpreting the data
* "Business logic"
* Formatting and pretty-printing of output
* Cleansing the data as it is stored into the database.

It is often wise (especially in more complex systems) to have a "database layer" in which the "business" info is transformed to/from "database" info.  On the database side, there is "INT" and "FLOAT"; on the business side, there are other terms for numeric things.  The business may say "store this"; the layer may turn that into one INSERT, or split the columns across two tables, or normalization plus inserts, or INSERT .. ON DUPLICATE KEY UPDATE .., or INSERT IGNORE, or an INSERT plus augment a summary table, or ...

Yes, some of those things could be done with TRIGGERs and FOREIGN KEY "cascading constraints", etc.  But I would rather put all the logic in a single place.  I find triggers clumsy to code.  I find FKs limted in capability.