Imperative to relational
A free email course on how to wrap your head around relational databases.
Avoid the common tripwires as you learn relational thinking.
Sign up now
SQL is like starting over
You've spent a lot of time and effort learning to express yourself in terms of loops and conditionals and how to decompose problems into functions.
Then you learn some SQL. Trivial things are fine, but as soon as you try to do something beyond a simple SELECT, those techniques you painstakingly learned seem useless. How do you write an if statement to change what a query returns? How do you combine data together without classes?
Maybe it would be better with a NoSQL system? MongoDB promises JSON documents…but once you've gone down that road a bit, you'll realize that what blocked you before is exactly the same.
You don't have to stumble blind
Learning a new ur-language is going to be brain bending. Doing it blindly is worse. Wouldn't it be better to hit a problem and say, "Oh, I was warned about this." and know what direction to take?
The jump from imperative programming to relational requires you to revisit three key assumptions about how programming works:
- We work with one piece of data at a time. Even if it is a collection, we treat the collection as one value and use loops to get single values out of it.
- Data has both its value and an independent identity apart from its value.
- We access data by having variables that give us handles to it.
If you go trawl forums and chat rooms, the problems people have adapting to relational programming all come back to these.
You can save yourself time and suffering by getting these assumptions out in the open, knowing what replaces them in databases, and how that applies in practice. If you've learned a SQL and tried your hand at designing a schema but felt lost, the Imperative to Relational email course will walk you through these differences.
Subscribe to the free course
I will not spam you or share your information with anyone. Unsubscribe at any time if you're not getting value from the course.
Who are you, anyway?
Hi, I'm Fred Ross. I've been building distributed data processing systems and web services since the 1990's. I've written two books, and I've engineered systems, advised on strategy, and taught classes for organizations like Facebook, the Swiss Institute for Bioinformatics, Fermilab, and Splunk.