SQL Isn’t That Hard (If You Have the Freedom to Experiment)

Haki Benita, Software Developer and Team Lead

Haki Benita’s start with SQL was, in his own words, “bumpy.” After graduating in Computer Science and Economics, the software developer got a position as an application database administrator (DBA) and honed his skills by making every mistake in the book—well, at least once. From endless time optimizing impossible SQL queries to crashing databases without backups, Haki evolved into a respected voice in the database community (with many helpful tricks to share).
While he does not use many PostgreSQL tools, he remains an avid blog reader and writer who thrives on the impact of his work, regardless of the technology involved. In this interview, he shares his reading recommendations, SQL beginner tips, and some honest advice: nothing beats hands-on experience.

What is your current role, and what does it entail?

I’m leading the development of a large ticketing and payment platform.

Do you remember your first interaction with computers, and what drew you to them?

My first interaction with computers was at a very young age, so I can honestly say that what drew me to the computer was Prince of Persia.

via GIPHY

When and how did you get into SQL? Can you give a brief overview of your history with SQL?

My start with SQL was a bit bumpy. I’ve been developing since I can remember, but I never actually knew much about databases, let alone that a role such as a database administrator (DBA) even exists. Most of my early training focused on conventional programming, topics like object-oriented programming, Java, C, and C#. I learned some SQL, but it was always beside the point.

My first role was as an application DBA when I finished my training. The team didn’t have a senior DBA or even a senior developer, just a project manager. My first task was setting up a data warehouse; I didn’t know what this meant. The only thing I actually had there was a bunch of those heavy, white, Oracle reference books, so I started reading.

I started with the basic concepts and worked my way through the performance tuning guide, the data warehousing guide, and the Very Large Database guide (I skipped the book about the Oracle Recovery Manager, RMAN 😂). This took some time, but I got to experiment a lot!

In retrospect, this was a blessing because I got to make every mistake in the book at least once—I crashed databases without having backups, and when I did have backups, I managed to corrupt them. I wrote lousy SQL and wasted a ton of time trying to optimize impossible queries. I used too many indexes, and then I didn’t use enough of them. I created impossible schemas and abused hints to make them work. You name it, and I screwed it up at some point. As time went by, I started making fewer mistakes and got a sense of what works and what does not.

What sort of background in computing did you have before getting into SQL? Do you consider it your specialty, or is it a smaller part of your programming repertoire?

I studied computer programming in high school and got my first degree in Computer Science and Economics. I also took a lot of Oracle DBA classes.

I consider myself an application DBA, so SQL is definitely a significant part of my repertoire, but I’m also fluent in Python and JavaScript / TypeScript.

“To take a lesson from my own book, I think there is nothing better than hands-on experience”

What problems were you solving when you first started learning SQL?

I mostly worked on data warehouse systems early on, so the issues I had to tackle were how to bring data from many systems together. This means extracting data from a variety of systems using different means, loading it into the database, cleaning it, and transforming it into something you can gain insights from quickly. It may sound simple, but it rarely is.

What problems are you solving with SQL now?

I mostly work on online transaction processing (OLTP) systems now, which have their own challenges. OLTP requires different indexing than data warehouses, with more locking and concurrency issues. On the other hand, long-running and ad hoc queries are less of a problem.

What were some of your favorite things getting into it? What did you find hard?

I really liked SQL and data warehouses after getting the hang of them. I also got very excited when I started with Python and web development. I still get excited when something I work on makes a big impact, regardless of the tech I use.

“I think blog posts from actual working developers have something you can’t always find in books”

What tips would you give someone just starting to learn SQL now? What resources would you advise?

To take a lesson from my own book, I think there is nothing better than hands-on experience. I know it’s easier said than done. I mean, where can a junior developer find a large database to experiment on? Especially if all they really want to learn is SQL (and nothing else).

One of the reasons I started writing is that I was reading a lot of blogs. I still do. I think blog posts from actual working developers have something you can’t always find in books. They speak from experience and present real-life use cases.

I also like to catch up on articles and discover new blogs on https://postgresweekly.com and https://dbweekly.com/.

You have moved from Oracle to PostgreSQL. Can you describe what motivated you to do so and what that learning curve was like?

When I was using Oracle, I worked for a large organization. They had licenses to use Oracle, so I didn’t have much choice. After I left, I looked for the closest thing and, luckily, landed on PostgreSQL.

I made the transition a very long time ago, but I don’t remember it being a traumatic one. There are still some things I miss about Oracle. Mainly some features of partitioning, fast refreshable materialized views, optimizer hints, and most of all— the naming convention of the dictionary tables.

What tools do you use to work with SQL/ Postgres in particular? For what purposes? Do you have a favorite that you evangelize for?

This is going to be a disappointing answer because I use very few tools. When I work with PostgreSQL, I use psql. When I was working with Oracle, I used SQL*Plus. I don’t use any editor, and I can’t think of a tool I use regularly.

What do you find frustrating about SQL or PostgreSQL in particular? What tools do you wish there were but can’t seem to find?

It would be great if we could just omit the GROUP BY clause (it is usually just a list of all the non-aggregate expressions in the SELECT clause). It would also be great if there were syntax for selecting * and excluding some columns. I also wish psql had the break skip command like in SQL*Plus. I used it all the time, but I can’t anymore.