In 1999, I was working as a tech support agent. My job was to field 32 calls or more a day because the company was paid for every phone call they handled. It was a different world then. The Internet was still relatively new and things like tech support websites weren’t commonplace.
They had a 2nd tier support group who essentially took the hard calls. While they weren’t on the phone, they answered questions from the rest of us. Someone decided to write down these answers, but there wasn’t a good way to get that info into the hands of everyone. They could print these out, but it wasn’t practical because things changed often.
One employee had basic HTML skills and started building an Intranet site (i.e. website only accessible from the local network). This was a new concept back then, and it was a huge success. Agents were able to field calls faster, which meant more revenue for the company.
This snowballed and soon the company started building a team around the Intranet FAQ site. Just before that, I finished reading HTML for Dummies1. With my newfound skills, I impressed them with a couple of web pages. These, of course, included a repeating background image and spinning animated GIFs. (Thanks Ed and Stephen - your book launched my career.)
We were on the cutting edge. As we learned new things, those things were incorporated into our solution. With continuous pressure to reduce costs for our clients, we soon shifted from getting paid per call to a flat rate. It was now more important to reduce the overall number of calls rather than just handle them faster. As part of this, we built a publicly facing tech support site so people could get their own answers. Like I said, it was a different world back then, and this was a new concept.
To make things manageable, instead of building a bunch of static HTML files, we learned ASP (now called ASP Classic). While learning ASP, I remember asking out loud, “What is a database? And why would I ever need to use one?”
This stuck in my mind because databases have become the central focus of my career. I’ve spent the last 20 years focused on writing code with an emphasis on making sure the database was as performant as it could be. As both a Software Engineer and a Database Administrator, having a deep understanding has defined my career and helped me stand out from the pack.
I’ve met hundreds of software engineers throughout my career. Even among those that focus on backend programming, there are very few that have a really good understanding of how a database works. I’ve noticed that people rely on their ORM too much and let it make too many of their decisions when it comes to how they interact with a database. Many barely know SQL, let alone how to reason about what the database is actually doing.
Over the years, I’ve interviewed hundreds of candidates for software engineering or DBA positions ranging from Junior to Senior. As part of the interview, I ask some basic database related questions. Most don’t know how to do a JOIN in SQL. Almost none know how to do a LEFT JOIN or even what it is. A lot of people resort to using code to do something that the GROUP BY clause was built for, and very few can do simple domain modeling.
This book is intended to open the black box and give you a deeper understanding about how these tools work. I’ll explain things such as the pros and cons to structuring tables in different ways, the essentials you need to know about SQL, how hardware affects things, and what is really happening under the hood. I’ll also compare different types of databases including relational, graph, and document stores and when they should or should not be used.
When Milliseconds Matter, you’ll have the foundation you need to get the best performance possible from your database.
ISBN-13 978-0764502149 ↩