All right moving on to likes so we've seen now users photos and comments and likes are a little bit
similar they are like the comment schema because when we think about how likes work on Instagram, at
least you like something you like the particular photo, let's say its corresponding to that photo.
We need to have an association there.
But then there's also the association between me, the person liking it and the like itself and that
might not matter if we allowed for infinite likes.
You know, if anybody could like something as many times as they wanted, just it was a button that
clicked and it just kept going.
Every time I clicked it, we could get away with not storing user information with a like.
But even then it might be nice to see how many times somebody had like something or how many likes,
you know, I in general, how often do I click the like button compared to somebody else?
It might be it might help us figure out who's a bot like on Instagram.
That's a big problem, actually.
Are these bots that people write that go in just like photos, like things all the time, create comments
that are just cookie cutter?
It's kind of frustrating actually, if you're a photographer because you know, you'll post something
and then you get excited that you have, you know, a hundred people who liked it.
And then it turns out a lot of them are.
But if you actually go try and look at them, they don't have any photos, posts, really.
They always comment the same thing.
Long story short, in this giant data set here, I actually coded in some bots that will be working
with basically people who aren't who aren't creating much stuff.
They're not posting many photos, but they are liking a lot of things in commenting a lot of the same
thing a lot of the time.
Anyway, back to likes it's going to look like this will have a user ID and a photo ID and a created
app.
So our user ID is going to refer to a user's ID and a photo ID refers to a photo ID and there's really
nothing else.
There's no information being stored there.
Maybe, you know, aside from the date or the time it was created when the like happened.
But what else is there to store?
You know, maybe Instagram is doing stuff like whether it was liked from the Web version versus the
iOS version.
Maybe they're storing other information here.
Possibly.
But for us, this is the basics.
We just need a user ID and a photo ID and every time you know, a photo is liked by a different user,
we get a new like just like this with the user ID and photo ID.
So we'll start by coding this.
You might have noticed that I didn't add an ID to likes.
I'll explain why in just a second.
But let's start by creating our table.
So we have create table likes and don't forget the semicolon.
We've got a user ID and a photo ID and are created at.
Let's start with create that.
We often neglect it.
Timestamp default now nice and easy.
User ID is just an integer.
I don't want it to be empty.
Same thing for photo id, but then we need to set up our foreign key constraints.
Foreign key user id references.
Users ID comma another foreign key this time photo ID references photos ID.
Okay, so now let's address why we don't have an ID here.
And the main reason is that we don't need an ID.
We're not going to be referring to likes anywhere else.
If we were, it would be good to add an ID there.
Maybe, but we're not having any table store information about likes.
The other thing you might be wondering about is how do we ensure that there's only one like per user?
Is there a way to do that in the database?
Because right now, if I did this, I could just insert let's say my user ID is one and a photo ID is
one.
I could insert a like with the user ID one, photo ID one, and then insert it again and again and again.
And there's nothing stopping that.
So what we really want to say is we want a unique combination of the two.
There can only be one instance of every combination, and there's actually a way of saying that and
we haven't seen it.
But you can do this primary key and then we can just say user ID, comma, photo ID.
So what this will do is basically not allow you to insert two likes that are exactly the same, the
same user ID and the same photo ID.
And I'll demonstrate that if you feel confident, if you trust me, there you can.
Skip.
Move on.
We're done with the schema here.
Let's just make sure that it runs.
I don't have any syntax errors.
Of course it does.
But if you'd like to see me try it out like the last couple of videos, I'll do that now.
So if you're still with me, all I'm going to do is take these photos and these users, and I'm going
to have some of them like them.
So let's take blue user ID one and that first photo, she created it.
That doesn't matter.
You can like your own photo on Instagram.
So we'll insert into likes.
And we have user ID come a photo ID, so the first one will be one comma one.
So I'm inserting a blue is liking this photo and then let's have Charlie Brown also like it.
So that would be a oops to come on one.
And then we've got the next photo here which has a photo ID of two, not this.
Remember, this is the user ID who created it, but this has an idea of two.
So let's say Blue also likes that one.
So blue ID of one likes photo ID of two and she likes photo ID of three.
And then let's say I have user ID three, I like photo with ID of three.
So let's start there.
We run it.
It works.
There shouldn't be any problems at this point.
But now if I try and do this insert into likes, user ID, a photo ID values and I do one comma one.
Well, that's not that.
There we go.
One, come on, one.
Which already is in there, blue user ID one.
And then this photo adds blah blah blah 76 with ID of one.
We already have that like.
But if I try it you can see I get duplicate entry 1-14 key primary.
So the way it does it is basically combines it to keep track of the combination like that with the dash
between it.
So that's pretty much it.
I will copy what we just did and add a note here.
If you're looking at these notes later, just saying won't work because of primary key constraint and
I'll comment it out as well.
We don't want to run that every time.
Great.
And next up, we're moving on to a fun one, which is relationships following followers, all that stuff.