Howto implement correctly Businness Logic in database I'm searching about how to disable triggers, and seems like it's not possible under MariaDB.

My problem is, how to manage then, when you import data.
I have a database where almost all business logic is inside it with triggers and stored procs. Probably, there are records autogenerated by triggers and stored-procs that were filled later by a user, and I don't know how to manage this if I import a database dump, or importing a csv file for example.

I'm sure the problem is I'm not seeing the obvious, and there are some problem in my data model, but because I'm starting with this project, I'm in time to modify what is needed, knowing best practices to take into consideration.

My question is, there are some best-practices to take into consideration, when we want to implement the business logic of an application, inside the database?

I hope I explained correctly.

This is a little Example coming to my mind: 
On a deployed database, there are a record that will be created from a trigger, and later, this record, is modified by the user. When import an sqldump, because this records exists, sql dump will fail trying to inserting this existing recods.
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.