項目中外鍵，應該用"userid"(帳號)仍是用user表"ID"

優缺點

表"ID"好處:

用id由於是int類型，比字符串類型的性能高得多，特別是在大數據量的狀況下。在數據庫的設計上，除非很是高級的系統，纔會考慮int快和慢的問題。

"userid"(帳號)

若是數據量比較大，有的狀況下須要考慮儘可能減小錶鏈接的操做

這種狀況咱們通常叫「邏輯id」和「物理id」

id------做爲數據的物理id標識

userid---------是數據的邏輯id

通常來講中小型項目一般使用物理id作爲標識，而大型項目每每使用邏輯id作標識。

區別，大型項目由於數據量大，結構複雜，網絡硬件配置複雜，網絡結構複雜，存儲介質複雜。他們一般採用分佈式的數據存儲介質和分佈式的網絡環境，而在分庫，分表的狀況下，數據庫的物理id就不可預覽了，因此更多狀況下使用邏輯id做爲標識

好比：銀行系統一般使用不與數據庫id關聯的，帳戶號作標識。而電信系統則由於硬件環境的限定使用電話號碼作標識（電信系統一般的前置機只認主叫號，被叫號這種邏輯標識，而不認你本身的數據庫id）

優化方案：

爲了提升性能能夠做數據冗餘。例如：字段比較多，數據量又很大，你能夠把Name字段上加入包含性列（不過這會佔用一點額外的存儲空間了）
可能修改的帳號字段定義爲loginid，用戶表使用id,userid,做爲標識。 UserName修改的機會要大不少，特別是企業應用，客戶若是要求改一下用戶名，若是用戶名是外鍵那影響就大了.

相關話題：

1. 外鍵約束會影響數據庫性能，因此考慮只做業務約束。
2. 錶鏈接也有技巧：儘可能用left join，不用inner join，這樣能夠提升效率
3. 一個同事認爲3次錶鏈接以上就極可能會有性能問題
4. 單機的狀況下,4次錶鏈接,主表20萬行,在E8400+2G的機器上,作Group By統計,運行時間超過半個小時.後來將3個錶鏈接保存爲一個視圖,再與主錶鏈接,問題解決,30秒內完成.（不知道用的什麼數據庫，我不太信）