项目中外键，应该用"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秒内完成.（不知道用的什么数据库，我不太信）