今天一同事问我怎么改db中user表的编号,系统中user表是建模生成的,编号设置成不可更改的,user表中主键是一个随机生成的ouid,一般公司为员工的中文拼音来作为编号。现在一客户要改user表中用户的编号(因为中文拼音可能重复,他们想改用号码作为员工编号),由于前台不能改,因此我想从db中直接改,为了不改错数据,我查了一些别的和user相关的表,发现有的表里引用的竟然是user的编号,并不是ouid,这样就有非常严重的问题了,我只改user表里内容的话,那别的表中数据就失效了。这里的严重错误是,别的表引用user应该用user表中的ouid,而不user表中的编号,ouid字段一经建立就不能改动。
上面的错误并不值得一提,但想到我以前做的一个选型系统,生成选型单号,单号以当前时间编码,精确到ms+3位随机数字,因此重复的概率几乎为0,我当时就想,如果我把单号作为主键就可以了,没必要再用系统生成的32位随机字符作为主键,用单号作为主键还有一个好处,就是单号是有时间规律的,我在查询选型单相关表的数据时,人眼可以一眼分辨出单号,而不会对一串32位字符发晕,但是如果要改单号的话,那就会引发一系列问题(当然,这个如果几乎没有存在的一天)。
因此,以后在设计表的时候,尽量不要让在UI上显示的字段来做为主键,如上面说到的用户编号和选型单号,虽然它们改的几率几乎为0,但是万一要改,牵一发而动全身,我建议是每个表用随机生成的字符作为主键,别的表引用时以这串字符作为外键,虽说感觉上数据有点冗余,但谁能保证客户哪天冒出这个需求呢。
上面的错误并不值得一提,但想到我以前做的一个选型系统,生成选型单号,单号以当前时间编码,精确到ms+3位随机数字,因此重复的概率几乎为0,我当时就想,如果我把单号作为主键就可以了,没必要再用系统生成的32位随机字符作为主键,用单号作为主键还有一个好处,就是单号是有时间规律的,我在查询选型单相关表的数据时,人眼可以一眼分辨出单号,而不会对一串32位字符发晕,但是如果要改单号的话,那就会引发一系列问题(当然,这个如果几乎没有存在的一天)。
因此,以后在设计表的时候,尽量不要让在UI上显示的字段来做为主键,如上面说到的用户编号和选型单号,虽然它们改的几率几乎为0,但是万一要改,牵一发而动全身,我建议是每个表用随机生成的字符作为主键,别的表引用时以这串字符作为外键,虽说感觉上数据有点冗余,但谁能保证客户哪天冒出这个需求呢。