MySQL Primary Keys

Explains what a primary key is, and why it's an integral part
of relational databases.

When we created our two tables, we also created a primary key for each table.

When you expand the nodes in the left SCHEMAS tab, you can see the primary keys
(and foreign keys—we'll get to those next) listed under each table:

As the accompanying screenshot shows, the Indexes nodes contain any indexes (in

our case foreign keys and/or primary keys). These primary keys and foreign keys
are only there because we specified them in our code when we created the tables.

Specifically, we used PRIMARY KEY (FruitId) to make the FruitId column the primary

key for the Fruit table, and we used PRIMARY KEY (UnitId) to make the UnitId column
the primary key for the Units table.
What is a Primary Key?
A primary key (also referred to as a unique key) is a column that has been allocated
as the unique identifier field. The value in a primary key column is unique to each
record. In other words, no two records can share the same value on that column.

A classic example of a primary key field is an "ID" field. Most tables will have an ID
field that provides a unique identifier for each record. Examples could include
"CustomerId", "ProductId", "FruitId", etc. Without ID fields like these your database's
function would be severely hampered. If you had two or more customers with the
same name, how would you be able to find their record? While it's true that you
could possibly find something unique about every record, it's a lot cleaner and easier
to have a column whose primary purpose is to provide unique identification for each
record.

A primary can can either be a normal value that is guaranteed to be unique (an
ISBN number for books, product code, etc), or it can be a value generated by the
application or DBMS specifically to be unique (such as a globally unique identifier, or
auto incrementing integer).

Choosing a Primary Key

Be careful when choosing a column for your primary key. You need to make sure
every record will have one, and that there's no possibility that two records will share
the same value, or that one record will have more than one value.

For example, using the user's email address might work in some cases, but it's not a
very solid basis for a unique identifier. Users can change their email address. Users
can share email addresses. Some users might not have an email address. Of
course, you could write your system to prevent users from changing their email
address or sharing it, but your system wouldn't be very flexible or user friendly.

You could require all users to have a unique username. That could work. However,
you need to think carefully about all possibilities. If there's any chance users may
change it or share it (past, present, or future) don't use it as a primary key. What if
"TechGuy12" de-activates his account. Does that mean another user can now use
"TechGuy12"? Will that be a problem for your application or any reports you need to
generate?
If you're in any doubt about the "uniqueness" of your primary key field, use an auto
generated number that increments with each record created.