Let’s face it, there are a lot of cool new things you could be learning right now. It seems like there’s a new technology coming out every 12.8 seconds. Why the hell would you want to spend your free time learning a crufty old language like SQL? My reasons, let me show you them.
It’s portable
Computer science students are taught hundreds of techniques and theoretical constructs while they earn their degree. A lot of that information isn’t directly applicable in day to day programming tasks, but it introduces students to fundamental constructs that they can move between platforms – they have a common vocabulary and tool kit that they can take with them wherever they go.
Although every database vendor implements their own extensions, with every new version the vendors are moving their databases to be in line with the ANSI/ISO SQL standard. Standards compliance, while tricky, makes it possible to take your knowledge from platform to platform. If you learn SQL, you’ll be prepared to move from one database to another.
It never changes
My good friend and business partner jokes that he became a DBA because SQL hasn’t changed in 35 years. This is, largely, true. Vendors have implemented their own extensions that eventually make it into the SQL standard, but the core of SQL doesn’t change. Once you understand the basics of SQL and relational theory (it’s not that hard), you’ll find that you can continue to build on that knowledge and add features and functionality that you were relying on other tools or developers to implement.
It’s an easy place for performance gains
There are only a few places to implement performance gains in an application – the presentation layer, the application layer, and the storage layer. Let’s face it, your code is already well written and well tuned; getting any performance gains there is going to be like getting blood from a stone. The database, on the other hand, is an easy place to make a few simple changes (add an index, change a query slightly) and see tremendous performance improvements. Having spent a considerable portion of my career as an application developer staring at a profiler, I can attest to this. It’s possible to pry performance improvements out of application code, but modern frameworks and toolkits are typically so well-written that the database is usually a better place (read as easier place) to find low hanging fruit for performance improvements.
It’ll make you a better developer
The Pragmatic Programmer challenges developers to learn a new language a year; not because the landscape is constantly changing but because learning new languages exposes developers to new paradigms. There are different ways of thinking about problems that can lend themselves well to different solutions (I’ve recently learned a lot from diving into functional programming). Learning SQL will teach you to think in sets rather than iteratively. In the long term, this will change the way you think about working with data and lead to improvements in your database code.
Improve communication across teams
Have you ever tried to talk to someone who spoke your language but spoke a wildly different dialect? Communicating across a language barrier can be difficult outside of work, but it can be outright maddening when the success of a project depends on it. Learning SQL will give you a leg up when you’re communicating your goals to the DBA team. They won’t have to decipher your meaning and you can tell them exactly what you need. In the end there will be less miscommunication, things will get done faster, and you’ll no longer be “that frustrating developer.”
Job security
I hate to say it, but learning SQL may mean that you get to keep your job when Ted in the next cube gets canned during layoff season. The more skills you have and the more job functions you can perform, the more valuable you become to your current employer (and to a future employer). If you can work with the database team and the development team, you’re now a valuable asset that both teams depend on for success.
It’s really not that hard
Contrary to popular belief, SQL is not a difficult language to learn. It’s a different way of thinking, that’s for sure, but it’s not difficult. There are only a handful of commands, operators, and data types documented in the ANSI/ISO standard. While vendors may add their own features, there’s a compact core of knowledge that you can learn and apply everywhere you go.
Know when it’s not appropriate to do something in the database
The database is a phenomenal tool for solving many problems, but it’s also a horrible tool for solving even more problems. To put it another way: you probably shouldn’t be digging a trench with a hammer. By learning and understanding SQL, you’ll be able to make better decisions and move poorly performing code out of the database. In fact, you’ll be able to spot these problems before they’re even problems.
Once you understand SQL, you’ll have a much better grasp on the limitations of an RDBMS. You’ll know which portions of an application can safely live in a database and which will need to be moved further up the stack to a different layer. Some data validations should live with the data, some shouldn’t. Understanding how SQL works will help you determine which rules should remain in the database.
Simplify troubleshooting
Live applications are notoriously difficult to troubleshoot. The more complexity and layers that are involved, the more difficult it is to troubleshoot an application. A good understanding of SQL makes it possible to rapidly isolate problems that do exist in the database. To put it a different way: understanding SQL makes it easy to locate the problem in one of many different layers of your application.
Want to Learn More?
Where do you go if you want to learn more about SQL?
32 Comments. Leave new
Nice post and thanks for the SQLU love!
The title should be “Nine Reasons Developers Should Already Know SQL”. There is no reason why developers shouldn’t at least know the basics of writing SQL queries. And I mean beyond Select, From, Where.
Nick – well, with a title like that, we might be a little inflammatory, eh? 😉
I can think of three reasons why developers shouldn’t at least know beyond Select, From, Where: the reasons are O, R, and M. A lot of developers believe the system will take care of that for ’em behind the scenes. I’m not saying I agree, but ORM marketing material slants that way.
It’s scary to acknowledge this, but we are probably at the point where many green devs have only used the ORM that is baked into their development stack (Rails, Django, etc…). Therefore, I like the original title.
Funnily enough, I really learned SQL as a result of troubleshooting the queries that my ORM was writing for me. I knew the basics of joins, but I fully got a handle on what was going on when I dug into the guts of the ORM to figure out why some things were slow.
I agree that ORMs make you lazy about SQL. I went the opposite route. Ten years ago I could write long, complex SQL queries. But over the past several years, I’ve gotten rusty thanks to using ORMs full-time now.
Thanks for this article, you have motivated me to go back and refresh my SQL skills!
“Learning SQL will teach you to think in sets rather than iteratively.”–I love this concept. I would also say that with the increasing prevalence of big data, SQL is the necessary foundation for handling it.
This is a brilliant post. I would share with people to insist learning SQL as a language.
Any decent IT or computer science school should teach relational theory and SQL. As it has been stated, there is no reason, other than laziness, why a developer should’nt know already basic-intermediate SQL.
Ironically, laziness is one reason to learn SQL. It solves so many problems beautifully and simply.
A different angle on this is that for a lot of companies, data transcends applications/UIs , and should be treated with great respect. Eg the semantics of the data should not be coupled to the architecture and mechanics of a particular application except perhaps meta data specific to an app
Agreed. I always advocate for a strict separation of “data logic” and “app logic” whenever I’m looking at architecture. Anything that I can get away with only writing once goes in the database. SQL has let me be professionally lazy and I’m very happy about that.
Definitely it never changes… cheers,,,,
we are facilitated with new functions instead for making our jobs done quite smoothly…
Great article!
I’m at an AS400 shop, and I’ve been the only one in my department to embrace SQL. It’s given me phenomenal flexibility in generating reports using some pretty complex criteria. Faced with the same challenge, others here would choose to spend much more time crafting a legacy program to get the report.
Gotta love the portability too!
The time spent learning SQL has paid rich dividends for me.
I can’t believe that devs don’t know SQL. I use an ORM in my job but I also have to move data using ETL tools from one place to another and therefore need to know SQL. I had two database courses in school and the final project of the second one was to create a database, fill it with data, and create several triggers and stored procedures with nothing buy SQL for an Oracle database. I couldn’t have graduated without learning SQL. I do like that you can take it with you anywhere. No one should rely solely on ORM. ORM is a convenience but shouldn’t be the end-all-be-all.
Exactly, I also had two database related courses. In the first we learnt about data modelling, ER models and basic SQL. We were encouraged to try at least one RDBMS, be it Postgres, MySQL, Access or SQL Server. In the second course we had to develop an app (PHP) from scratch, do the analysis, create the data model and the ER diagrams.
IMHO, if you don’t go through similar process in your studies or career, well, you must not call yourself a developer, programmer, software engineer or any other title, you’re just a code monkey.
Yeah sure, there is ORM, but rely only on it, without knowing what the hell is going on in the inferior levels is not the right way to do things.
Don’t forget that there are a lot of developers who never studied computer science in college but ended up in their profession some other way.
Not all education programs are the same. Many people I’ve worked with only took a single database class in college and had to pick up additional knowledge on the job. No matter how you go about it, there’s no guarantee that the classroom knowledge will stick around or that it was taught well.
Disparaging people because they don’t know SQL isn’t going to fix the problem.
I agree with you, that’s why I made the comment on laziness. If someone’s into being a GOOD developer, who implements best practices and do serious programming, he/she should learn SQL, and more important, understand relational theory; no matter when, no matter how, no matter where, it’s an effort that must be done. And there are plenty of resources to learn from, lots of tutorials, and open source RDBMS that are free to download, install and use.
I first ran across SQL years ago, fortunately just before I got to data structures and linked lists in C. I was top of the class because of it because I had a practical framework that helped me figure out how to design my C structures. Been using it ever since for all sorts of uses. My favorite is using it to analyze equipment performance based on tens of millions of test records. Found a 10ppm timing error from 37E6 records in seconds because I knew what could possibly be useful when I did the data design, how to create the necessary data records, and could run aggregate functions against it.
I can honestly say that I haven’t stopped using SQL since I learned it. The whole discipline of data design helps me come up with objecdt designs in C++, C#, and Ruby.
I couldn’t agree more with you. Thanks for sharing this.
Thanks Jeremiah, I really enjoyed your comments, it’s encouraged me to keep building and improving my SQL skills to excellence. I like cheesecake, coffee and ice cream too, sometimes all at the same time.
As a SQL Server database developer with over 10 years experience, I’m usually very disappointed in developers who do know SQL — and prefer to work with database developers over programmers who know SQL.
This usually revolves around your statement”…Learning SQL will teach you to think in sets rather than iteratively. …”. I’ve found that developers have no idea about set theory. Their knee-jerk reaction to looping is to create a cursor rather than looking at alternative, and more likely better, solutions.
where I’m currently working there are dozens of cursors in the stored procedures created by programmers. By comparison in 10 years I’ve created one cursor.
I saw the same thing at a previous job. I coached the developers through a basic understanding of set theory and they were able to do that part of their job better. In turn, they helped me write better C#.
Understanding how sets work is getting more and more important for developers, especially with many of the changes going on in the .NET framework and how easy it is to get additional performance out of a database.
Reason X: It will give you an edge (in the job market) over most of your competition so long as you can find a software house that appreciates this knowledge/skill and its value.
I used to work with a software company (specialized market) that employed over a hundred coders/developers/ and not a single one (to my horror) even wanted to learn SQL.
The problem there was one of mindset that was propagated from the top and that was this:
“Anyone can learn SQL in a 2 hour class so why should we pay top dollar to send someone to a weeklong class or to hire someone who is a SQL specialists?”
They had no clue at that time of the importance that SQL plays when dealing with RDBMS like SQL Server or Oracle. At that time the average clients database was no bigger than a few hundred MB and so any novice could write a horrible query and it still work fine in as far as performance goes.
Jump ahead 10 years and now (from what I’ve heard) and clients have databases measuring hundreds of gigabytes and so now a lot and I mean a lot is having to be re-written to correct past mistakes.
If you didn’t have $700 to buy an Oracle package what would you use to learn SQL.
Ted – well, we’re actually Microsoft SQL Server folks, but I’ll take a stab at that anyway. Pick up the book “SQL for Dummies” – it sounds ridiculous, but it’s actually great because it teaches you ANSI-compliant SQL that will work across multiple database platforms. Hope that helps!
I’ve also been a fan of the “Visual Quickstart Guide to SQL”. Like SQL for Dummies, it’s a guide to ANSI SQL – everything will work on Oracle, SQL Server, or whatever you work with next.
Once you’ve finished that and feel comfortable with ANSI, I’d look into Oracle specific extensions to SQL. If you like books, you can pick up Feuerstein’s PL/SQL Programming (which doubles as a boat anchor) or head over to the Oracle documentation where you can hit up the “2 Day Developer’s Guide” and supplement that with the PL/SQL Quick Reference.
Interesting article.
Recently, a recruiter tried to hire me, but lost interest once he realized that I don’t know SQL. I hardly ever work with databases and so I never thought that it would an important language to learn. However, I think that I would like to learn it so that I can have more job security and so where can I go to learn it?
Faylinn – start with Google.
interesting?
I’ve also been a fan of the “Visual Quickstart Guide to SQL”. Like SQL for Dummies, it’s a guide to ANSI SQL – everything will work on Oracle, SQL Server, or whatever you work
It is very good course for learns and help a lot and also useful the experienced people and refresh the once.