数据库主键方案

1、坚决不可以用某个业务字段做主键,理由就不说了,业务都是有意义的,你能保证它产生的规则不变吗?

2、如果要汇总两个库表,id很多重复,那为什么要把A表的数据导入到B表,为什么程序不能自己到2个表中去查询呢,再说了,数据大了还要拆表呢

3、GUID作为主键,mysql本身并没有这个数据类型,oracle和sql server都有,它的缺点为:1、存储空间比自增型大很多;2、主键在这上面做索引,怎么保证有序,全是毫无意义的一串数字,效率低下,所以mysql本身就弃用了此方案

4、还有一种方案是使用两套主键,一个是数据库自增的主键(pk),另一个就是我们认为的业务“主键”(不是数据库上的pk),根据它去做数据的findById和关联查询,它的实现方案是用自定义的数据库表存储某个表当前的业务“主键”值,然后同步控制读取+1去实现,当然在读取值时,使用了
conn.setTransactionIsolation(Connection. TRANSACTION_SERIALIZABLE );
避免在多个实例并发时的问题,但是这是最高的隔离级别啊,可想而知效率会怎么样;另外,就算在同一个jvm中的synchronized也很要命,这种方案也不是好的选择
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值