0

I have a table like this

user(#id, login, password)

But i want to make it just like 

user(#login, password)

because the login is unique for each user

I want to know if this is a good solution ? it will affect speed (performance) with a primary key with long char (indexes) ?

Hayi
  • 6,972
  • 26
  • 80
  • 139

1 Answers1

0

This is always a fun question. It is actually a long debate in database design, "natural" vs "surrogate" keys.

Since this is question isn't quite a duplicate of just that, I'll put an answer but also some links to the core issue since it is well-covered.

Like most database performance question, it ultimately depends. :)
If your login is short and/or you don't have a large number of logins, you may not see much difference from an integer key.
You might also think about if someone is ever allowed to change their login... if so, you will want the surrogate integer to let you keep the key.

For more about this as a general question, and some other folks' tests on performance:

Deciding between an artificial primary key and a natural key for a Products table

Surrogate vs. natural/business keys

http://en.wikipedia.org/wiki/Surrogate_key

Community
  • 1
  • 1
Mike M
  • 1,382
  • 11
  • 23
  • From your link "IMHO always favour surrogate primary keys. Primary keys shouldn't have meaning because that meaning can change. Even country names can change and countries can come into existence and disappear, let alone products. Changing primary keys is definitely not advised, which can happen with natural keys." Which is exactly what I advised, yet apparently having a strong and experienced opinion on the matter gets me downvoted whilst a generic "it depends" answer wins? Obviously a user login can change, obviously it can be quite large, so obviously the PK should be an int. – Janine Rawnsley Jun 20 '14 at 18:43