MySQL 10 - Summary of Relationships
This video will be a summary of what you have learned with relationships in the last 3 videos. The first thing we learned is that a one-to-one relationship is the equivalent of a column inside of a table. There is no need to store it in a separate table unless you are doing it for a specific reason, such as separation. The example I gave in this situation was storing a user's image in a users_image table. A one-to-many relationship requires two tables. One table will be designated as the table for the one side of the relationship and the other will be designated as the many side of the relationship. The many table will have a foreign key to the primary key of the main table, but the main table has no foreign keys. A many-to-many relationship is broken up into two one-to-many relationships. This gives us the end result of having an intermediary table that associates a specific entity with another entity. The example I gave was a specific user being associated to a specific listing. If a user posts multiple listings, the user's ID will repeat but the listing ID will not. If a listing is owned by multiple people, the listing ID will repeat, but the user's ID will not. Now, I have a question for you. Let's say we have a users table and it has a column named first_name. Now we have two people create an account and they both have the same name. Is this a one-to-one relationship, or a one-to-many relationship? Pause the video and think on it for a few moments. I would classify this still as a one-to-one relationship even though there is redundant data. That's because if you think of what a first_name is designed to do, you quickly realize that it is used to define an individual. It just so happens that two people have the same value for their first_name. When you say a specific person's name, you do not refer to everyone who also has that name. If you did, then that would be a one-to-many relationship. I know, there is a fine line between the two. If you are in this kind of situation, I recommend just asking yourself, "Do these entities share this attribute, or is it just by chance that they both happen have the same value?" Good examples of columns that could repeat but are often considered to be part of a one-to-one relationship are names, email addresses, phone numbers, addresses, titles of things (such as listings), etc. To think through this a bit more, let's say two people commented on a blog post on our app, and they both said the same thing. Would it be appropriate to have a table called comment_content, and then in the comments table have a foreign key that references that specific comment's content? No, that would be ridiculous. It would be much easier to just have the same value twice inside of the Comment table. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Support me! www.patreon.com/calebcurry Subscribe to my newsletter: eepurl.com/-8qtH Donate!: bit.ly/DonateCTVM2. ~~~~~~~~~~~~~~~Additional Links~~~~~~~~~~~~~~~ More content: CalebCurry.com Facebook: www.facebook.com/CalebTheVideoMaker Google+: plus.google.com/+CalebTheVideoMaker2 Twitter: twitter.com/calebCurry Amazing Web Hosting - www.dreamhost.com/r.cgi?1487063 (The best web hosting for a cheap price!)
