最近检查代码质量、看到有写primaryKey = MAX(Id) + 1的做法,总让我有些不爽,虽然是新闻类的网站,对主键的要求不是很严格,关联的数据也不复杂,但是总觉得这样的做法,不是很妥当。

 

   原因之一:

   若这个表里的数据很多很多,索引也没有建立好,MAX(Id)的运行效率不会非常高,当然这样的情况比较少发生,但是有的时候这个做法也会引起一些并发问题,当然是一个表里插入时会很少发生这样的问题,若有相关的子表什么的,很可能会引起并发冲突等,当然我们也不希望总是遇到那种复杂的情况,总的来说不是很稳妥。

 

   原因之二:

   很早很早的时候,做OA项目,那时候也没大主意,主键就靠这个产生,主表产生了1、2、3、4、5,然后5被删除了,重新又生成了5这个主键,但是莫名其妙的,5个子表没对上,原因虽然是出在我们程序没处理好,当5被删除时,子表里的数据忘记被删除了,若是子表又有子表,那这个问题就更复杂了,每次写程序都能写得天衣无缝还是比较困难的,当然后来不直接删除数据了,只是打上了删除标记,虽然这个问题被间接的解决了,但是总是觉得这样产生主键的方式不是很妥,总是会引起一些没必要的麻烦。

 

   原因之三:

   若一个公司有2个分公司,每个分公司都有自己的信息系统,总公司需要把数据进行合并,这时候大家产生的主键都是1、2、3、4,不好合并数据,把数据直接导入到一起,会引起额外的麻烦,这时候主键是越简单越好,表结构也是越简单越好原则,能直接把数据库放到一个表里,其他什么也不管了是最理想的处理方式。

 

   原因之四:

   以前的某个公司,做一个医院的项目,由于系统不稳定,导致给A病人开的药会跑到B病人哪里去,开始测试阶段发现了几次这样的现象发生后,这个系统就被废弃了,这搞不好是要出人命的呀,我估计,其中一个关键问题,就是数据的关联主键没处理好,导致主键产生的算法不严谨,关联关系有漏洞,导致这个项目失败的原因会很大,虽然我没看过人家的源码,也没参与这个项目,但是多年的职业感觉告诉我,主键上出问题了,主外键关系是一个管理系统的命脉。

 

   虽然主外键关系是一个很简单的东西,但是这个东西做得天衣无缝、让人觉得心服口服,效率又高,思路又严谨就很难了。

   1:是否能保证唯一性?并发情况下?分布式运行情况下?  

   2:执行效率问题,主键产生的速度足够快?

   3:主键是否能适当保证信息的安全性? 1,2,3,4,傻瓜都能猜测出来,下一个是5?6?7?

   4:主键算法能否支持多数据库,越简单兼容越好。

   5:别人是否好调用你的主键产生算法?

   6:是否在一定程度上避免了错误产生的可能性,例如程序员比严谨导致的业务上的重大错误,例如医院的那个?

   7:将来是否好维护好扩展?

 

   随便说说吧,到目前为止看了很多主键的产生算法、做法,真的做得很圆满,很不容易,把一个简单的东西彻底吃透很不容易,能知道存在哪些问题,哪些不足也很难,天天想着去改进了,天天想着问题会在哪里也很难。

   其实很多问题,都在我们的工作中存在,我们需要把工作中的问题,一个个都解决好,避免给客户造成重大损失,能解决工作中的缺陷漏洞才是人才,而不是学到死了,也没做出啥玩意儿来,强很多,学那么多,就是为了在工作中用到,解决工作中的点点滴滴问题,小问题太多了最终就全盘崩溃了。

 

 

一步步教你如何用疯狂.NET架构中的通用权限系统 — 如何控制用户显示的菜单权限
一步步教你如何用疯狂.NET架构中的通用权限系统 — 在页面中的调用权限讲解
一步步教你如何用疯狂.NET架构中的通用权限系统 — 数据集权限的调用权限讲解
一步步教你如何用疯狂.NET架构中的通用权限系统 — 分级管理
一步步教你如何用疯狂.NET架构中的通用权限系统 — 分级授权

疯狂.NET 通用权限设计 C\S后台管理,B\S前台调用源码样例程序×××之 — 操作权限
疯狂.NET 通用权限设计 C\S后台管理,B\S前台调用源码样例程序×××之 — 角色权限
疯狂.NET 通用权限设计 C\S后台管理,B\S前台调用源码样例程序×××之 — 数据集权限

 

 

  

将权限管理、工作流管理做到我能力的极致,一个人只能做好那么很少的几件事情。