数据库自增字段的使用问题?
有几种说法:每一张数据表必须要有一个主键,如果无法选出合适的字段则使用自增字段;自增字段具有业务无关性,具有高效率;那么我想知道的是:自增字段在何时使用,比如我的用户表已...
有几种说法:
每一张数据表必须要有一个主键,如果无法选出合适的字段则使用自增字段;
自增字段具有业务无关性,具有高效率;
那么我想知道的是:自增字段在何时使用,比如我的用户表已经有用户名可以唯一地作为主键,还需要用自增字段吗?如果使用了自增字段,在进行外键关联时绑定到用户表的自增编号还是用户名呢?
另外,如果用户所属某个部门,这个部门又属于某个大的部门,需要将两个属性都作为用户表的字段吗?这样会具有更高效率吗? 展开
每一张数据表必须要有一个主键,如果无法选出合适的字段则使用自增字段;
自增字段具有业务无关性,具有高效率;
那么我想知道的是:自增字段在何时使用,比如我的用户表已经有用户名可以唯一地作为主键,还需要用自增字段吗?如果使用了自增字段,在进行外键关联时绑定到用户表的自增编号还是用户名呢?
另外,如果用户所属某个部门,这个部门又属于某个大的部门,需要将两个属性都作为用户表的字段吗?这样会具有更高效率吗? 展开
4个回答
展开全部
自增字段在何时使用,比如我的用户表已经有用户名可以唯一地作为主键,还需要用自增字段吗?
那就没有必要了,主键都有了,要那个字段只会浪费空间。
如果使用了自增字段,在进行外键关联时绑定到用户表的自增编号还是用户名呢?
自编号没有实际逻辑意义,当然用用户名了
如果用户所属某个部门,这个部门又属于某个大的部门,需要将两个属性都作为用户表的字段吗?这样会具有更高效率吗?
恩。一定程度上会,这样减少表连接,通过牺牲存储空间来换效率就是这样一个例子。
那就没有必要了,主键都有了,要那个字段只会浪费空间。
如果使用了自增字段,在进行外键关联时绑定到用户表的自增编号还是用户名呢?
自编号没有实际逻辑意义,当然用用户名了
如果用户所属某个部门,这个部门又属于某个大的部门,需要将两个属性都作为用户表的字段吗?这样会具有更高效率吗?
恩。一定程度上会,这样减少表连接,通过牺牲存储空间来换效率就是这样一个例子。
追问
也就是说自增字段只是用来做主键,可是我还听说自增字段的业务无关性,又怎么解释了?
追答
不解释了,基础问题,你多动点脑筋想想很容易明白的。
展开全部
用自增编号,尤其在存在外键关联的时候
如果用户所属某个部门,这个部门又属于某个大的部门,需要将两个属性都作为用户表的字段吗?这样会具有更高效率吗?
=======
会的,这个属于数据冗余范畴的问题,要注意保持数据的一致性。
如果用户所属某个部门,这个部门又属于某个大的部门,需要将两个属性都作为用户表的字段吗?这样会具有更高效率吗?
=======
会的,这个属于数据冗余范畴的问题,要注意保持数据的一致性。
追问
一般什么时候需要这样做呢?
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
展开全部
1)自增做主键更灵活
比如:如果表1选择用户名做主键,那么用户名就不能更改,否则将导致其它表关联数据会混乱(如果表2记录的是用户名来与表1关联的话)。
2)关于部门的问题,用户表只要记录部门,不需要记录 大部门
否则,修改部门所属的 大部门 时,需要同时更新用户表中的大部门字段,如果程序逻辑不严谨,容易引起数据不一致问题
比如:如果表1选择用户名做主键,那么用户名就不能更改,否则将导致其它表关联数据会混乱(如果表2记录的是用户名来与表1关联的话)。
2)关于部门的问题,用户表只要记录部门,不需要记录 大部门
否则,修改部门所属的 大部门 时,需要同时更新用户表中的大部门字段,如果程序逻辑不严谨,容易引起数据不一致问题
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
展开全部
看你表的关系,有的唯一主键就可以了,有的还要用到两个主键,一般一个主键都用编号
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
推荐律师服务:
若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询