My disagreements with Using Native SQL instead of ORMs

I came across a post with a course aimed at developers. Let’s work through the stated objectives of the course:

It will have live interactive sessions about the benefits of using native SQL instead of object-relational mapping.

The obvious drawback to native SQL is that your application objects want to talk to other application objects – and an object-relational tool expedites this. Who wants to muck about in SQL query syntax in their Python? Not I!!!

And then we have object-relational masterpieces like CubicWeb which take a graphically defined semantic model and automatically creates database tables and CRUD for you.

I looked at the curriculum for this course and it does not prepare you for high-level Pythonic sourcery like Cubicweb.

The students will learn to model schemas and tables

Our DBAs do this. I’m not interested in being involved in this.

write SQL queries

OK cool. This is important. But a $29.95 book can teach me this.

The students will learn to tune SQL queries

Our DBAs do this. I guess if I wanted to expand my horizons I might be interested in this, but I have enough balls to juggle on a daily basis without being an expert in something that is largely irrelevant for our type of work.

The students will learn to do data processing.

Hmm, interesting. The course is open to Java, Javascript and Python developers. And there are specialized ETL tools in each language for this. As a professional, I find data processing to be highly specific to the task at hand. And when I do need a particular approach, Stack Overflow is just one URL away.

Conclusion

If you are aiming to be the best of the best in all aspects of your application stack, then this looks like it might have some merit. On the other hand, each topic of this 4-week course could each have 4 weeks devoted to it. And where I work, we have certified professionals with years of training in databases – how to design them, write stored procs, tune queries, etc.

This course might be of interest to someone. But not me. I have enough on my plate with keeping my Python code bug-free. And adding SQL to the mix only confuses things. I will stick with the old synchronous dog SQLAlchemy for now and have the DBAs created well-tuned views and stored procedures for me to access.

Leave a Reply

Your email address will not be published. Required fields are marked *