Why use an auto-incrementing primary key when other unique fields exist?

Question

I\'m taking a course called \"database systems\" and for our class project I have to design a website.

Here\'s an example of a table I created:

CREATE TA         


        

Answer 1

Because someone might want to change their username (or any name for that matter).

Answer 2

For instance, integer search (?id=5) is much way faster and has higher cardinality than string search (?username=bob). Another example, uid is auto_increment, so you don't have to insert it explicitly but it will auto increment in each insert query.

PS: Your prof is soooo wrong about it :D

Answer 3

I go with all the answers above. I would say an ID is easy to implement and when it comes to indexing, Int is always preferred compared to a varchar. Your professor should know better, why would he say no to Int id is above me!

Answer 4

This is typically called a surrogate key and it has many benefits. One of which is insulating your database relationships from the application data. More details and the corresponding disadvantages can be found at the wiki link provided above.

Answer 5

we use ID to prevent duplication data and it can make some procces become not complicated (if we want to update or delete data), it more simple if we use ID.

if you dont want to use ID you can use another fields. but dont forget to make them become UNIQUE. it can make your data become preventive from duplication data.

another way outside PRIMARY is UNIQUE.

Answer 6

If you have demonstrated to your professor that assigning a unique arbitrary integer to each user is of value to your application then of course he would be wrong to say that it is "completely useless and unnecessary".

However, maybe you missed his point. If he told you that the requirement is that "no two users can have the same username" then you haven't met that requirement.

Sincere thanks for posting your SQL DDL, it is very useful but most don't bother on SO.

Using your table, I can do this:

INSERT INTO users (username) VALUES (NULL);
INSERT INTO users (username) VALUES (NULL);
INSERT INTO users (username) VALUES (NULL);
INSERT INTO users (username) VALUES (NULL);
INSERT INTO users (username) VALUES (NULL);

Which results in this:

SELECT uid, username, passhash, email, rdate 
FROM users;

uid   username   passhash   email   rdate
1     <NULL>     <NULL>     <NULL>  <NULL>
2     <NULL>     <NULL>     <NULL>  <NULL>
3     <NULL>     <NULL>     <NULL>  <NULL>
4     <NULL>     <NULL>     <NULL>  <NULL>

I think is the point your professor was trying to make: without enforcing the natural key on username you don't really have any data integrity at all.

If I was the prof, I'd also urge you to remove nullable columns from your design.