一般建表时我这样做:
stuno int pk,
sname varchar ,
class carchar ,
sex varchar
最近看到这样的:
id int pk,
stuno int ,
sname varchar ,
class carchar ,
sex varchar
请问第二种方式有什么好处？或者为什么要这样做？
谢谢大家！！
6 个解决方案
#1
用户可见的字段，哪怕现在用户、需求说唯一、不会变，也不要设置为主键
应该增加一个内部的自增id（用户不可见），作为主键——即第二种做法
这与数据库无关，与中国国情有关：
现在口口声声说不变的字段，只要是用户可见的，就有可能：日后用户领导说要变，用户就要求变的
应该增加一个内部的自增id（用户不可见），作为主键——即第二种做法
这与数据库无关，与中国国情有关：
现在口口声声说不变的字段，只要是用户可见的，就有可能：日后用户领导说要变，用户就要求变的
#2
加上"PRIMARY key"？
#3
现在很多高并发网站都这样设计，这种设计，把一个自增的ID当做主键，但却没有实际意义。
这么设计的思想，我认为：
1、现在应对高并发的复杂WEB设计，为了达到解耦的目的，去除了外键的设计。
2、因没有外键，主键的意义除了防重和自带索引外，我知道的没有其他的用处了，因为防重我们可以用 inser xxxx where notExit ... 来处理
3、使表更灵活，对索引的添加删除、表结构变更 都有益处。
这么设计的思想，我认为：
1、现在应对高并发的复杂WEB设计，为了达到解耦的目的，去除了外键的设计。
2、因没有外键，主键的意义除了防重和自带索引外，我知道的没有其他的用处了，因为防重我们可以用 inser xxxx where notExit ... 来处理
3、使表更灵活，对索引的添加删除、表结构变更 都有益处。
#4
恩恩，不好意思，我简写了！
你知道那个是为什么吗？
你知道那个是为什么吗？
#5
1，业务实体层，用标识列作为主键
2，支持层，如果一个表从来不作为另一个表的主表，则用复合主键。
#6
id int pk, --应该是这样吧 id int identity(m.n) primary key
stuno int ,
sname varchar ,
class carchar ,
sex varchar
第二种设置其实主要是为了防止后期主键变更所带来的维护不变，用自增字段也就是标识字段不影响整体数据表
#1
用户可见的字段，哪怕现在用户、需求说唯一、不会变，也不要设置为主键
应该增加一个内部的自增id（用户不可见），作为主键——即第二种做法
这与数据库无关，与中国国情有关：
现在口口声声说不变的字段，只要是用户可见的，就有可能：日后用户领导说要变，用户就要求变的
应该增加一个内部的自增id（用户不可见），作为主键——即第二种做法
这与数据库无关，与中国国情有关：
现在口口声声说不变的字段，只要是用户可见的，就有可能：日后用户领导说要变，用户就要求变的
#2
加上"PRIMARY key"？
#3
现在很多高并发网站都这样设计，这种设计，把一个自增的ID当做主键，但却没有实际意义。
这么设计的思想，我认为：
1、现在应对高并发的复杂WEB设计，为了达到解耦的目的，去除了外键的设计。
2、因没有外键，主键的意义除了防重和自带索引外，我知道的没有其他的用处了，因为防重我们可以用 inser xxxx where notExit ... 来处理
3、使表更灵活，对索引的添加删除、表结构变更 都有益处。
这么设计的思想，我认为：
1、现在应对高并发的复杂WEB设计，为了达到解耦的目的，去除了外键的设计。
2、因没有外键，主键的意义除了防重和自带索引外，我知道的没有其他的用处了，因为防重我们可以用 inser xxxx where notExit ... 来处理
3、使表更灵活，对索引的添加删除、表结构变更 都有益处。
#4
恩恩，不好意思，我简写了！
你知道那个是为什么吗？
你知道那个是为什么吗？
#5
1，业务实体层，用标识列作为主键
2，支持层，如果一个表从来不作为另一个表的主表，则用复合主键。
#6
id int pk, --应该是这样吧 id int identity(m.n) primary key
stuno int ,
sname varchar ,
class carchar ,
sex varchar
第二种设置其实主要是为了防止后期主键变更所带来的维护不变，用自增字段也就是标识字段不影响整体数据表