OOP vs DB programming

ajchv23 profile image Alberto Chaves ・2 min read

Hello, as you can see this is my first post, I'll try to write about the programming languages that I know, and any other topic that I consider it's important for me to remember.

To begin with this blog, I want to talk about the difference between object oriented vs database programming, there's a lot to talk about, but I will focus on what has been my experience working with these two paradigms.

In the last six years I've been working mostly with database programming, the process to create a stored procedure could be very uncertain, if there isn't a clear process and specially a standard to follow, you could feel a dangerous freedom at the moment to write your code. I understand the advantages of using database programming for example, the speed to deploy changes in production and the easy to modifying the data, to name a few. But the fact that you don't have to compile all the project before deploying in production, it can bring many problems. For example, if a colleague adds a new parameter in a function, he don't need to modify every stored procedure/function/trigger where the function is called, and the function will compile successfully. Then when another colleague execute a stored procedure where that function is being used, he will see an error in execution time,
which could be avoided. That kind of cases happens every day, because both the language and the programmer don't have the obligation to do so. Here comes the need to set rules and a standard that everybody must adopt.

By the other hand, when you develop with object oriented programming, it gives you a path to follow, I'm not saying that OOP resolves all the technical issues you encounter in the way, but makes the process a little bit neater and cleaner, and in mostly cases errors happens in compilation time, which is the right moment to correct it and make the adjustments necessary to a good deploying in production. Another advantage is the using of design patterns through interfaces and abstract classes which can be a quite clear path to walkthrough into a problem. It's nice to mention, that always you need to adopt a standard to get everybody in the right direction, in developing is quite easy to get a system into a completely mess, if you don't have people concerned for the correct applying of the company rules, and maybe the most important, for the language guidelines.

This is just a question about how many companies walks into a cloudy tunnel, when we talk about techniques of how to develop their systems, how to grow and how certain people choose these paths almost without thinking about the future.

Posted on by:

ajchv23 profile

Alberto Chaves


My interest are cooking, camping, hiking and especially programming...


Editor guide