Solution: Tailored to Fit
Let's learn how you should use keys in the database.
We'll cover the following
NA primary key is a constraint, not a data type. We can declare a primary key on any column or set of columns, as long as the data types support indexing. We are also able to define a column as an auto-incrementing integer without making it the primary key of the table. The two concepts are independent of each other.
In short, don’t let inflexible conventions get in the way of good design.
Tell it like it is
We should choose sensible names for our primary key. The name should convey the type of entity that the primary key identifies. For example, the primary key of the Bugs
table should be bug_id
.
A quick way to check if a value exists in one table while inserting an entry in a second table is by using a foreign key. We must use the same column name in foreign keys where possible. This often means that the name of a primary key should be unique within our schema; no two tables should have the same name for their primary key unless one is also a foreign key referencing the other. However, there are exceptions: sometimes it is appropriate for a foreign key to be named differently from the primary key it references so as to be descriptive of the nature of the association.
Get hands-on with 1400+ tech skills courses.