2011-06-28 86 views
2

這是一個用於用戶管理的數據庫設置,我在互聯網上找到了某處(用僞代碼編寫)。雖然看起來非常好,但我不明白爲什麼users表有一個id以及一個唯一的非空username列。我不能只使用用戶名作爲id(主鍵)?使用用戶名列代替id?

users 
(
    id integer primary key, 
    username varchar(100) not null unique key, 
    pwd varchar(50) not null 
); 

user_roles 
(
    user_id integer not null, 
    role_id integer not null, 
    unique key (user_id, role_id), 
    index(user_id) 
); 

roles 
(
    id integer primary key, 
    role varchar(100) not null unique key 
); 

回答

6

我總是回到Kimberly L. Tripp的recommendations for a clustering key(默認情況下,它是SQL Server中的主鍵)。

她的標準是聚集鍵應該是:

  • 獨特
  • 精細(1爲ID)(ID和名稱之間並列)
  • 靜態(可能 1爲ID ,取決於名稱是否允許更改)
  • 不斷增加(可能對於ID,取決於它的實現方式,在此使用IDENTITY列將是理想情況)
+0

+1不能說更好 –

2

這將使連接到它效率低下:int s爲比varchar(100)小得多,因此指數會更小,快捷。通常,主鍵是表格的聚集索引。

4

是的,你可以使用用戶名。問題是潛在的易變主鍵很痛苦,因爲您需要將更改級聯到所有FK。

而且使用整數連接中往往表現得更好

你應該注意到,是什麼讓一個關鍵的波動是有些主觀

同樣作爲JNK提到有一個優化可以了,當一個聚集索引(通常也是PK)是一個增量int請參閱Kimberly L. Tripp的文章The Clustered Index Debate Continues

+0

+1 - 而且還因爲它是你的聚集索引鍵在SQL Server插入性能會更好用增量int而不是隨機放置的varchar。 – JNK

+0

@JNK謝謝忘了那個。更新了包含該位的答案 –

1

基本上,ID是存儲在數據庫中用於在DB腳本中引用的自動增量值,儘管用戶名也是唯一列。最大的優點是您的用戶不需要記住任何已分配給系統登錄帳戶的數字號碼,而是可以選擇他們自己的唯一用戶名並輕鬆進行交互。

4

您可以(使用user_id作爲主鍵)。

的唯一的問題我看到的是這樣的:如果要被改變(斯蒂芬妮·史密斯出嫁到名爲約翰遜一些傢伙,需要她user_id改變)以往任何時候都需要user_id,那麼它是數據庫的維護更少。

我在哪裏工作,有人設置我們的數據庫使用user_id作爲主鍵年前。改變現在將是一場噩夢!

另外,int搜索速度更快,並且可以自動生成。

2

我認爲你可以使用用戶名作爲主鍵。也許這個例子使用id列來獲得更好的性能。我猜,搜索Int列的速度要快於文本列的速度。在user_role表中還有一個foreign_key user_id。在這種情況下使用字符串(100)作爲外鍵是沒有意義的。

2

在高層次,您可以在這裏談論Natural與Surrogate Keys。有權衡,這兩個我覺得已經提到,但如果你想更多的閱讀中,我會說這個鏈接概括起來很好

"Natural and Surrogate Keys"

+0

+1 Thx爲鏈接,我可以獲得每一點信息:-)。 – helpermethod