请稍等 ...
×

采纳答案成功!

向帮助你的同学说点啥吧!感谢那些助人为乐的人

自增还是不靠谱 token还是有拦截获取

自增主键
这种方式是使用数据库提供的自增数值型字段作为自增主键,它的优点是:

(1)数据库自动编号,速度快,而且是增量增长,按顺序存放,对于检索非常有利;

(2)数字型,占用空间小,易排序,在程序中传递也方便;

(3)如果通过非系统增加记录时,可以不用指定该字段,不用担心主键重复问题。

其实它的缺点也就是来自其优点,缺点如下:

(1)因为自动增长,在手动要插入指定ID的记录时会显得麻烦,尤其是当系统与其它系统集成时,需要数据导入时,很难保证原系统的ID不发生主键冲突(前提是老系统也是数字型的)。特别是在新系统上线时,新旧系统并行存在,并且是异库异构的数据库的情况下,需要双向同步时,自增主键将是你的噩梦;

(2)在系统集成或割接时,如果新旧系统主键不同是数字型就会导致修改主键数据类型,这也会导致其它有外键关联的表的修改,后果同样很严重;

(3)若系统也是数字型的,在导入时,为了区分新老数据,可能想在老数据主键前统一加一个字符标识(例如“o”,old)来表示这是老数据,那么自动增长的数字型又面临一个挑战。

MySQL(auto_increment)、SQL Server(IDENTITY)、Informix、Oracle(首先创建自增序列,接着为自增主键的表创建插入时的触发器,给自增主键ID赋值)等数据库都支持这种自增主键,这种主键在各种系统中应用广泛,但是如果考虑到有新旧系统并存等问题,为了避免不必要的麻烦,使用自增主键要三思。

GUID主键
目前一个比较好的主键是采用GUID(Globally Unique Identifier,全球唯一标识符),GUID的特点如下:

(1) 在空间上和时间上具有唯一性,保证同一时间不同地方产生的数字不同;

(2) 世界上的任何两台计算机都不会生成重复的GUID值;

(3) 需要GUID的时候,可以完全由算法自动生成,不需要一个权威机构来管理;

(4) GUID的长度固定,并且相对而言较短小,非常适合于排序、标识和存储。

可以将GUID主键定义为字符型,但值由GUID生成,GUID是可以自动生成,也可以程序生成,而且键值不可能重复,可以解决系统集成问题,几个系统的GUID值导到一起时,也不会发生重复,就算有“o”老数据也可以区分,而且效率很高。在SQL里也可以使用 NewID()生成。主要优点是:

(1)同 IDENTITY 列相比,uniqueidentifier 列可以通过 NewID() 函数提前得知新增加行的ID,为应用程序的后续处理提供很大方便;

(2)便于数据库移植,其它数据库中并不一定具有 IDENTITY 列,而 GUID列可以作为字符型列转换到其它数据库中,同时将应用程序中产生的GUID值存入数据库,它不会对原有数据带来影响。

缺点是:

(1)GUID值较长,不容易记忆和输入,而且这个值是随机、无顺序的。

(2)GUID的值有16个字节,与其它诸如 4 字节的整数相比要相对大一些。这意味着如果在数据库中使用 uniqueidentifier 键,可能会带来两方面的消极影响:存储空间增大、索引时间较慢。

正在回答 回答被采纳积分+3

1回答

7七月 2020-02-21 01:58:57

不知道你的这些是自己的想法还是看了什么教程。

很负责任的说,自增就是比较好的做法。

第一个 手动插入ID字段这本来就是不规范的,如果你有 自定义的标识你可以用另外一个字段标识,既然是自增的就不应该手动插入。

自增主键唯一的问题是多个数据库合并的时候 主键会重复,但这个再分布式数据库里本身就是由统一的中心主键配发器来给不同的分布式数据库分配ID,保证唯一。

GUID作为主键非常不好,可读差、性能差。

0 回复 有任何疑惑可以回复我~
  • 提问者 lqh_zlx #1
    我公司的后端是采用时间戳和加一些规则 一套算法 形成一个ID ID长度16位以内!这样在排序上也没啥问题!老师觉得这样会有什么问题
    回复 有任何疑惑可以回复我~ 2020-02-21 08:13:36
  • 7七月 回复 提问者 lqh_zlx #2
    数据量大的时候查询会很慢。
    回复 有任何疑惑可以回复我~ 2020-02-21 13:02:57
问题已解决,确定采纳
还有疑问,暂不采纳
意见反馈 帮助中心 APP下载
官方微信