At the heart of almost any software project is data. There are few skills more useful than being able to efficiently pull the data out and manipulate it to your desires.
There are normally two bottlenecks that will slow your application down. These are:
If you are developing web applications, I would hazard that 90% of the time your application is slow, I/O is the bottleneck and is most likely because of how you’re requesting data from your database.
This is why learning how to efficiently structure, index and query your database is so important.
This is a series about SQL, not NoSQL!
If I were to bite though, I’d say you are almost certainly better off with a relational database. There are a couple of cases where this is not the case:
The most important thing to remember about databases is that they’re slow! Reaching out to a database over a network, connecting, sending it your query, getting it to run your query, then bring the data back is a (relatively) slow operation.
If you ever find yourself in a for/while loop and querying a database, take a step back and think about what it is you’re doing. Depending on the number of times you’re looping, it may not matter, but it’s a good indication that you may be doing something very wrong.
The second most important thing to remember about databases is that they’re fast. Incredibly fast. Amazingly fast. The efficiency of what they’re doing is far beyond whatever you’ll achieve in your own code, as such the key to performance is making sure you’re asking the database the right question.
A lot of software developers learn SQL by hacking about to get what seems to work, so I’ll quickly skim over the top level basics.
All databases that implement SQL loosely implement the ISO/ANSI spec (I love it when specs that the world is built on are put behind pay barriers, I’m looking at you ISO8601). As such, they all tend to have some base similarities, but once you start using fancier features (UPSERT/IF/JSON) you’ll find that each database has it’s own unique syntax and way of doing things.
This document should generally be sound for MySQL or Postgres (although I’ll be mostly writing syntax for MySQL). Each of them has their own quirks however and I would recommend you read the addendum page for your database of choice.