经常有版友问我：“老汉，你说的鬼打架是什么意思？”

 

　　起先觉得这就是一个口头禅没什么好解释的，但是问的人多了就觉得是个问题了，私下里仔细琢磨了一下，这个问题还应该是个有趣的问题。

 

　　“鬼打架”是一个地域性的俗语，大慨的使用范围在湘、鄂、徽、赣一带，也就是故称的楚地。什么时候什么人开始使用这个俗语，恐怕无法考证了。但是有一个古戏似乎与其有些许联系。楚一带很多地区现在仍然在民间保留着一个叫做儺戏的东西，也就是一种古典的祭祀活动。表演者化妆成各种恐怖的鬼神造型，伴随锣鼓围绕篝火翩翩起舞，有一种通灵的意味，似乎是要表现与逝者的交流，祈求祖先保佑。这种表演看起来很像鬼打架。

 

　　“鬼打架”从字面上来看，至少带有恐怖、惊悚、奇怪的含义。但语境不同，“鬼打架”也会表现出多种不同的意味。在我看来这三个字大体可以根据语境做如下的翻译：面目可憎、胡说八道、义愤填膺、无可奈何、不可理喻、莫名其妙、狗屁不通、精妙绝伦、风姿绰约等。大约都带有一些极端的情绪，可能是积极的赞许也可能是消极的鄙视。

 

　　“鬼打架”一语可以说是含义宽厚深远通古通俗的高雅用语，但凡大智若愚大雅若俗处，皆可用此简要三字表达。

 

　　鬼打架的，说的有点啰嗦了，回到问题上来吧。

 

　　昨夜饮酒到十点左右归家，上得QQ，版友芊芊同志留言一个问题。说是有两个数据表，均为外链MySQL数据表。一个数据表为企业人员工资表，其字段名称皆为汉语拼音写就；另一表为一个字段名称的对照字典，也就是说汉语拼音对照的汉语。他希望通过一个查询将字段名直接翻译为汉语。看了这个问题我便觉得有些鬼打架，便告诉他这就是一个别名的问题，不需要对照表，直接在查询中写字段别名即可。他依然坚持要用代码处理，我便有些烦了，不搭理他，和美女版友聊天去了（当然不涉及风花雪夜，皆为纯技术探讨）。

 

　　芊芊同志继续发来很大一段文字，看看了，便打断了与美女版友的聊天，因为这个问题有点意思了。芊芊同志说有几十上百个字段需要处理，这说明用直接在查询中写别名是不道德的。于是想了一下，便觉得需要用记录集来处理。花了十来分钟，给他写了两个函数，其一是用数据集结合创建查询的语句实际创建一个工资查询，其二是不实际创建查询，而是用函数返回一个SQL语句的字符串。写罢两个函数，酒往上涌，睡意朦胧，便洗了个澡，倒头与周公交流去也。

 

　　一觉醒来，还觉此问题有鬼打架之处。其一是工资表的字段数与对照表的记录数莫名其妙的逻辑不符，应该来说对照表的记录数应该大于等于工资表的字段数，结果我看到的是相反的情况；其二是工资表的字段实际需要几十上百个字段反映吗？显然是扯淡的事情嘛。因此这个问题的完整处理，应该是选择性的创建查询或SQL语句。

 

　　到论坛看了一下芊芊同志的帖子，发现纵云梯同志有一个解答，下载下来看看是否已经考虑了这些问题。发现解答的思路不对，纵云梯同志按照芊芊同志的极端错误的想法采用了另外创建数据表的处理方法。此法的不妥之处在于：其一链接数据与创建表之间不易解决同步性问题，其二原始数据已然存在，多一表便冗余了。因此这个解法也是鬼打架。

 

　　由于从问题到解答存在一系列鬼打架，便觉得有必要写一个示例来进行正确的引导了。于是乎便写此例，供芊芊、纵云梯同志参考。这个问题的有意义，其实不在于解决的具体方法，也不在于解决的思路，有意义的是问题分析过程。问题的分析过程通常与代码没什么太大关系。问题的分析首要解决的是理解问题，其次是观察问题的细节，再次是对问题做分解。这三个步骤完成后，解决的思路、实现的方法通常都不会是难点。就如同“鬼打架”一语具有万能用法一样，此一思维方法也是放之四海而皆准的普遍真理。

 

　　最后再对芊芊同志的一个鬼打架想法，做一个结论。这就是直接用工资表和字段对照表编写查询在ACCESS中或者不可能或者过于复杂，且这个问题也没什么实际意义。因为你需要做窗体、报表数据源的ｓｑｌ语句可以按照我所提供的方法得到。这个问题的核心在于SQL语句本身的规范中别名是不能采用变量的，但存在一个鬼打架的看似相反的论断：SQL语句字符串中的别名可以通过变量获取。基于这两个判断，服务器端和客户端均可处理。要想直接用这两个数据表编写查询，SQL　Server中可以通过表值函数或者存储过程来处理，MySQL中如果有类似功能也可处理，这种处理是在服务器端的处理。客户端的处理就是我现在提供的用数据集的方法处理。

 

　　写罢此文，觉得自己有点鬼打架了。结论似乎过于肯定，万一有好事者把结论推翻了怎么办呢？算球，厚一次脸皮吧。有说得不对的地方，请同志们批评指正。

 

点击下载此附件