Member-only story
DB 101: Databases for Developers
A few overlooked aspects of working with databases
Over the past few weeks, I’ve been doing some deep-diving into databases as part of my day-job effort to migrate our existing Postgres 9x databases to something more recent, like Postgres 13. As an SRE I don’t typically have much exposure to the database layer of the applications that I support beyond making them available and ensuring migration scripts and the like run successfully. But this deep-dive has allowed me time to get to know our databases and their structure and to see some of the inner workings of our applications. Out of this has sprung a few articles so far (and a few to come, stay tuned!) but today I want to talk about databases — specifically relational databases — from the perspective of a software developer and maybe help some new and aspiring developers understand their data stores a little better.
Picking the Right Tool for the Job
The first thing I want to talk about is probably the most controversial topic on this list, and that’s choosing the right database for your application. Now, I understand that not everyone will be in a position to choose the DB for their project, but I think it will be helpful to understand a few of the most popular DBs and their pros/cons.
First, there’s the matter of DB type: relational, non-relational (or NoSQL), and key-value (or KV).
Author’s note: One thing I want to point out is that the dichotomy of SQL vs. NoSQL is sort of a misnomer in that a relational DB doesn’t have to use SQL and non-relational DBs can use SQL. But SQL and NoSQL have become shorthand for relational and non-relational, so I’m going to use this colloquial meaning of these terms for the rest of the article.
Relational databases — sometimes abbreviated as RDBMS or SQL databases — store two kinds of data: the various bits of data that populate the database and the relationships between those bits. This allows SQL DBs to be flexible in their querying and make it easier to only get the data you’re looking for, as the data tends to be broken up across tables (or normalized) more than in a NoSQL DB. Normalization reduces data redundancy and improves data integrity, as you only need to store one bit of data a single…
