Hollywood loves a good sequel. Just this year alone we’ve had:
- XXX: The Return of Xander Cage
- Resident Evil: The Final Chapter
- Fifty Shades Darker
- Despicable Me 3
- T2: Trainspotting
- Alien: Convenant
- Pirates of the Caribbean: Is anyone still watching?
There’s method to the apparent madness, of course. Sequels are made when some semblance of success was seen with the original.
And when your budget is in the hundreds of millions, the people stumping up these vast amounts want themselves a significant return on that investment. It makes sense to play the percentages.
The games industry follows suit, and again just a short round up of 2017’s releases include:
- WWE 2K17
- Zelda: Breath of the Wild
- Warhammer 40k: Dawn of War 3
- Mario Kart 8
- Final Fantasy 49.2: Yet Another Merciless Cash-in
With all this talk of sequels I figured it’s about time CodeReviewVideos got in on the action.
It’s time for a course on SQL 🙂
Yeah, yeah, I know, only granddads like me still say it as “Sequel”. All the cool kids just say the letters – S-Q-L. But that would have ruined an enjoyable introduction to this post.
What I’ve found is that I’m getting many questions from users of Doctrine where, when probing a little deeper, I’m finding the basics of SQL are somewhat of a mystery.
I liken this to my recent forays into learning the Elixir language, and the Phoenix framework. I know, I know, I never shut up about Elixir / Phoenix, but please hear me out:
It’s super easy for me to forget what it’s like to experience Symfony, or Doctrine for the first time. I’ve been working with the Symfony ecosystem now for about four years and – thankfully – I’m largely over that frustrating phase of figuring it all out.
When I swap to a new language or framework (or both), I am rudely dumped back into the position. And it is rarely enjoyable.
Regardless of language / framework, there are some common problems we need to address in our day to day lives as developers. A big one of these problem areas is working with the database.
Now, the good news is that whether you’re working with MySQL (or a derivative), Postgres, or MSSQL (and likely Oracle but I have no first hand experience here), the vast majority of SQL is the same.
What this means is that regardless of learning Laravel, or Symfony, or Django, or Rails, if you know the basics of SQL you have a head start on learning your framework’s method of DB interaction.
Before I started using Symfony I had years of experience with SQL. Largely raw SQL as it happened. Stuff like:
SELECT * FROM blah
SET name='new name'
ON table_whatever.id = different_table.something
Even so, when I saw DQL I didn’t feel entirely confident.
Even worse, we don’t just have DQL. We have DQL, the Query Builder, and if need arises, we can drop down the Native SQL.
So here’s what we are going to do:
We’re going to start with the basics.
We’re going to spin up a database server, create ourselves a user, and a table, and we’re going to put some data in to that table.
Then we will learn how to do some basic queries.
SQL is really quite repetitive, which is a good thing as there aren’t that many things to learn individually. It’s really just about stacking a few concepts together to manipulate our data into a shape we want / need.
We will learn how to create, read, update and delete data directly using SQL.
We will then take what we have learned and map this – as close as possible – to the way Doctrine will expect us to work.
From here we can start getting a little more advanced. Updating our data, and deleting it too.
Then we will move on to situations where we have related data in two or more tables, and we want to bring everything that is related together in one query.
Joins, in other words.
Again, first we will look at Joins without Doctrine, and then we will figure out Joins with Doctrine.
If you have any queries (ho ho) or questions regarding SQL that you’d like to see covered in this series then please hit reply and let me know, and I will do my very best to cover them for you.
This week saw three new videos added to the site.
We’ve done everything we need to do except cover a test-driven approach to Deleting Wallpapers. Let’s fix that up in this, and the next video.
We are continuing with our test-driven (PhpSpec) approach to Deleting an existing uploaded Wallpaper, and making sure the associated image gets deleted too.
Learn how to quickly and easily add a secured Login Form to your Symfony 3 EasyAdminBundle admin back end setup with this free tutorial
There are a couple of remaining parts of this project that need addressing. Both of these will involve refactoring and clean up, primarily around the service definitions. Mostly though, for phase one of our Wallpaper website, this is a wrap.
Things will get a little more advanced as we move into Phase two, but this won’t be for a few weeks time as there’s an accumulation of videos / topics that need to be covered in the mean time.
Anyway, enough from me. As ever, thank you very much for reading. I hope you have a happy weekend and happy coding 🙂