Why should I create an ID column when I can use others as key fields? Possible Duplicate:
  Why use an int as a lookup table&#39;s primary key?  




So far, I'm accustomed to creating an ID column for every table and it is practical in a way that it makes me not think about decision making about primary key theories.

The professor in my university suggested the class to make primary keys from one or more fields which make up to one unique info about each column. And yes, I want to have a habit of applying natural keys instead of surrogate keys. On Wikipedia, the advantages and disadvantages of surrogate keys are listed, I strictly recommend This Article

I have seen people use integer ID fields for everything and nobody judges this method because


it "looks" efficient
a number field is used and it looks cooler because of its size per
row in memory


I am beginning to think an extra ID field is just creating redundant data with no actual benefit. So why should I create an ID column when I can use other columns as key fields?


If your ID field is 32 bits, it's equivalent to 4 ASCII characters
already.
If your Id field is 64 bit integer, it's 8 characters string so it
doesn't actually save that much of  memory (what implied here is the memory used on comparison. extra id column is already adding to the memory used (both HDD and RAM) )
An extra ID field doubles your indexing cost because you will also
    index a unique field you can use as a primary key.
You make extra joins if you need the data you could have used as a key field, for example, if you stored a unique user ID in one
blog post, to show the name of the author, you make a join query, if
your key field was the author's name, you don't need to join because
you store the relevant data in the blog post table. a foreign key
field with meaningful data reduces the need for subquery or join





Creating an extra id field "adds" to the memory load, it's not a
replacement of a unique string field, you are not replacing a
char-varchar field with an integer, you are adding an extra
column and it creates extra data flow. so any comparison of
data store should be done between "string" and "int+string". adding
an integer id field does not save space.


on the other hand


assigning a primary key data which gets value from user input, can be
problematic because people can enter, for say, their social security
number wrong and the actual person who wants to register won't be
able to register because of the unique policy. This can be
circumvented by adding extra digit or digits to the original number. 


Extra resources:


Comparison of Natural vc Surrogate keys


My conclusion from reading articles is that I should use natural keys whenever possible instead of skipping thinking about natural keys and using surrogate keys each time, as if it is a standard.
1 - It's faster.  A JOIN on an integer is much quicker than a JOIN on a string field or combination of fields.  It's more efficient to compare integers than strings.

2 - It's simpler.  It's much easier to map relations based on a single numeric field than on a combination of other fields of varying data types.

3 - It's data-independent.  If you match on the ID you don't need to worry about the relation changing.  If you match on a name, what do you do if their name changes (i.e. marriage)?  If you match on an address, what if someone moves?

4 - It's more efficient  If you cluster on an (auto incrementing) int field, you reduce fragmentation and reduce overall size of the data set.  This also simplifies indexes needed to cover your relations.

EDIT

To the specific points you just added:

1 and 2 - It's still much quicker to compare an int than a string, space considerations aside.  You are also conveniently ignoring overhead needed to store length of variable length fields (normally 2 bytes per field per row).

3 - If you cluster on the ID field then it doesn't add anything extra.  It SAVES space since you are using a more efficient row id.

4 - And then when that person changes their username your links all break.

5 - You really don't know what you are talking about here.  You do have to store the data, that's correct, but it's much more efficient to index and JOIN on the int than on a combination of other fields.