Database Design 27 - Foreign Key 

Paul French Of course not, and it would be horrible if it did. That would also imply that if you have a table with users (where there is a varchar column called `name`), and two of those users were named David; when one of the Davids changes his name to Mark, the other one would have his name changed. That is never supposed to change automatically, in the real world, or a digital one. Unless you have specifically designed your table to do so because of your own internal reasons that are familiar to you and make sense for your scenario.

Amanda Knapton my advise is to just study your face off on the matter. School will try to tell you there is only 1 definite right way to do things, but this isn't always the case. Often it is though.Learn every concept in this course. They will cover all of the subjects covered in class likely. Any other questions can be left in a comment.

Thanks Caleb, you are very good in your videos! Regarding this primary and foreign key business, Lets say *PtID# is the primary key in a table, in the next table I would have it as the **foreign key so that I will have the direct relationship... but then what would the *primary key of my second table be since the PtID# seems to be the only unique identifier in the table but it is already the foreign key? follow? I'm just trying to get a basic understanding because this a relatively small part of the class content, and maybe 35% of the final grade... theres a group assignment due saturday and then our database individual assignments are due in a month. With other assignments due before that and moving on to different topics. Thanks again! p.s. I'm also not so savvy about how youtube comments even work... so ummm hopefully after I leave the library I will be able to find your reply...have so much to learn.

I'd tell you how to find your reply but that would kinda be pointless :P The second table...what is it for? What is it storing? Whatever it is storing will have a primary key. So I'm guessing PtID# is pateint ID number or something? Well if you had a table for diet plans you would have diet plan ID (PK) and PtID (foreign key). It might not be the same example but you can apply it the same.

Foreign key columns can allow duplicates if the column is labeled NULL-able. That's because they are purely a reference and the db restrains you from doing dumb stuff.

CalebTheVideoMaker2 thank you for the reply Caleb much appreciated:) I think I've near enough watched your entire series!

I think it would be a m:n because you are connecting essentially two data tables/entities to one or more rows in another table.

+Bharat Chandra there can never be two primary keys. There can be composite keys or surrogate keys, though. If you don't have enough to make each row unique, consider adding a column or two!

There can't be more than one primary key in a relation (table). Therefore you might think about choosing another key as primary. Although, if you can't choose another one, you might consider creating a composite key or a surrogate key. A composite key combines multiple attributes so that you can uniquely identify a row. For example, in a given table where you have attributes like name, surname, address, phone#, neither of these attributes alone can uniquely identify a row. But if you consider all or some of them together, then you will be able to uniquely identify a specific row. This is how you create a composite key: CREATE TABLE CONTACT( Name VARCHAR(20), Email VARCHAR(50), PRIMARY KEY (Name, Email) ) A surrogate key, instead, is just an incrementing ID that you create every time a new tuple is created. That way you will always be able to uniquely identify a row. This is how you create a surrogate key: CREATE TABLE CONTACT( ID int NOT NULL AUTO_INCREMENT, Name VARCHAR(20), Email VARCHAR(50), PRIMARY KEY (ID) );

+Mohamed Elhariry can you please explain the difference a bit more?

+Mohamed Elhariry can you please explain the difference a bit more?