【日期：2010年4月24日下午】

【分类：项目开发经验】

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

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

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

原因之三：如果一个公司有两个分公司，每个分公司都有自己的信息系统，总公司需要把数据进行合并，这时候大家产生的主键都是1、2、3、4,不好合并数据，把数据直接导入到一起，会引起额外的麻烦，这时候主键是越简单越好，表结构也是越简单越好。

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

虽然主外键关系是一个很简单的东西，但是要把这个东西做得天衣无缝，让人看了心服口服，效率又高，思路又严谨就很难了，比如说要考虑下面这些情况：●是否能保证唯一性?在并发情况和分布式运行情况下呢?●执行效率问题，主键产生的速度足够快吗?●主键是否能适当保证信息的安全性?1,2,3,4,傻瓜都能猜测出来，下一个是5,6,7?●主键算法能否支持多数据库，越简单兼容性越好。

【●别人是否能方便地调用你的主键产生算法?】

●是否在一定程度上避免了错误产生的可能性?例如程序员不严谨导致的业务上的重大错误。

●将来是否好维护、好扩展?随便说说吧，到目前为止看了很多主键的产生算法、做法，要真的做到圆满很不容易。把一个简单的东西彻底吃透很不容易，能知道存在哪些问题和不足也很难，天天想着去改进，天天想着问题会在哪里出现也很难。

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

信息系统，分层不要过多，静态方法也可以考虑适当用用日期：2010年4月28日下午分类：项目开发经验很多年前，我们公司第一次用C#.NET写程序，大家积极性都非常高，研究技术也是热火朝天。当时公司里有几个高手，的确让人不服不行。在当时的环境下分层什么的搞得特精通，连WebService等时髦技术，也几下就搞明白了。公司按最牛X的技术方式、最合理的分层结构，设计了崭新的系统，大家都觉得非常满意。

结果所有的层加在一起，好像有五六层吧，一层套一层，中间全部是用WebService桥接。所有的方法，都通过调用WebService来访问，大部分处理逻辑也都写在服务器端，即使拿现在的技术标准来讲，也不差到哪里去。

大家开发了好几个月，东西是出来了，但是中间发生了很多事情：●大部分程序员，都无法深入理解技术架构，只是依葫芦画瓢，根本没深入体会人家的用意。

●当时没有众多成熟的第三方组件好选择，很多页面上的控件只能自己做，效率比较低。

●写了N多的接口，每个层都有，一个地方有变化，至少要修改五六个地方，累得要死，天天改来改去的。

●中间调用了WebService,程序一运行慢得要死，比原来的VB程序还要慢很多。

●用了崭新的C#语言，大家对语法也不熟练，做出来的东西不稳定，错误很多，一直无法通过测试，修改个没完。

●新开发的东西无法按时提交，老的系统又需要维护升级，有限的开发人员又被拆分成了两拨队伍，谁都想学新技术，都想放弃VB的老系统。

结果几个月下来，新系统没能成功上线，老系统又没能集中精力持续改进，给公司造成了几百万的损失，使公司元气大伤。

【我想说明的意思是：】

●玩新技术是有代价、有风险的。

●准确的定位决策能让一个公司发展壮大，错误的决策能让一个公司破产。

●写程序不要分过多的层，除非是真有必要。

●按客户需求做，只要能满足要求，越简单越好。最笨最简单的往往最见效。

很早的时候，由于对C#的语法理解不够深入、开发经验不多，做了很多接口，方法什么的虽然都是可替代的，但都是动态方法，非static的，也没有什么单一实例，程序的运行速度总体上来讲很慢。我这几年也经常比较，为什么我的系统总是感觉运行速度慢?static的方法，在不影响并发问题、不存在并发冲突的情况下，速度明显会快很多很多，反复new一个类，自动回收一个类的整体速度，还是没有static来得快，以前排斥static的方法，整个系统没有一个static方法。几年后，再看看手上的代码，不时会碰到static方法，也不怎么排斥它了。

一个公司单纯研究技术离走下坡路就不远了。我们研究技术，应该依附在客户的需求上，离客户的实际需求不太远时，才能实现最大的经济价值。