Question

I’m starting with Databases. I’ve been playing around with MySQL and Informix, but never had a real life project.

What is the real responsibility of a Database? Should we add Store procedures and functions to de Database or just let it to be a data repository with no logic?

Answer 1

Generally it’s considered good practice to not place business logic in your database. The main reason is maintainability. It is ok to use stored procedures still, but including business logic within those stored procedures makes your application harder to debug and update.

Including business logic in your database will also effectively tie you to using that one DBMS, and not allow the data layer to remain independent from your application. For example, you may encounter performance and scalability problems with one DB once your application is live, but due to business logic scattered throughout the db, migrating to a more scalable database will be time consuming at best.

If business logic is kept in application code (eg java or c#) and the data layer is abstracted using a data abstraction layer, and an ORM if language permits, then interchanging databases is much less problematic.

We should be striving for separation of concerns, and keeping business logic out of the db helps achieve that.

edit: There are also performance concerns which may dictate that stored procedures are a good place to keep business logic. Containing logic within the data tier (ie the sproc) in some cases reduces the many round trips between the data abstraction layer and the database, which can give a performance boost. I’ve worked on systems like this in the past, for this reason, but I’ve always found then difficult to maintain. The problem being that you can look through the classes and procedures to see the business logic and think that’s it and you will not see how a particular bug or process can be occurring, then you’ll find the stored procedure and see the other half of the business operation (a real pain when the sproc is a 1000 lines!)

As with many things, where you place your business logic depends on the particular problem you’re trying to solve.