The picture below is a database diagram I generated using SQL Database Management Studio. First of all, I have intentionally stored the students’ first and last names separately, as you can see from my database design. By doing this, when we pull records, we can either use the students’ first or last names instead of typing their full names out for better efficiency. Similarly, in order to even possibly consider using student names as primary keys, both first name and last name would need to be in the same field to create some level of uniqueness because primary keys cannot and should never be a duplicate value.  However, even in this scenario, we would still encounter the issue of students having the same first and last names, so it would not entirely alleviate this issue. And therefore, the best way to do that without complicating the record and table sets is to create a separate field called StudentID to identify each student individually and uniquely. This concept would theoretically and practically apply to faculty or educator tables when the time comes to create one. This concept is similarly applicable to the StudentActivity table. In our example above, since each club will also need to be identified individually and uniquely, a ClubID key is necessary, very similar to that of StudentID. Then, we would need to create some links to the StudentRecords table. Hence, since each club will have multiple StudentMembers, we would just need to add the StudentID to each club ID. So when the time comes to join the two tables together to see the names of the students in each club. The person can pull the StudentActivity table records and join them with the Student Records table while also including each student’s first and last names. So, in short, and to summarize, the StudentID is the primary key in the StudentRecords Table, whereas the StudentID is a foreign key in the StudentActivity Table, and the ClubID serves as that table’s primary key.

Responses to the professor or other students:

Response One:

Yes, the reason why StudentID is one of the best primary keys, in this case, is that there are no repeating values that would complicate and confuse two records. In order to be considered for a primary key, it would need to satisfy a couple of criteria; the first and most important criteria are to be unique, and second, it cannot be a primary key in another table. In my own discussion response, I have designed the StudentActivities table with the primary set as ClubID and StudentRecords table as StudentID. This way, both tables will be uniquely identified in their respective table, with StudentID also being a foreign key in the ClubID table to establish the much-needed linkage between the two tables when joining them together.

Response Two:

I like the design you have implemented for your tables. However, I do want to make mention that two tables cannot really have or theoretically have exactly identical primary keys. This reason for this is because when you are joining the tables together, you cannot join two primary keys together; it would have to be one primary key to one foreign key. This is most commonly seen in the one-to-many database table relationship.