Jeroen的同事很不幸被指派去修改一个古董级的老程序里的一个时隐时现情况不明的bug。“好消息是,我已经把问题定位到了一个数据库SQL里,”他告诉Jeroen,“坏消息是,我把问题定位到了一个数据库SQL上。”
得知这位同事对数据库问题并不是很有兴趣,Jeroen说愿意提供帮助。在回复中,Jeroen收到了下面这张图片。
“我想没人能帮得了我,”他的同事写道。
[英文原文:The Query of Despair ]
Jeroen的同事很不幸被指派去修改一个古董级的老程序里的一个时隐时现情况不明的bug。“好消息是,我已经把问题定位到了一个数据库SQL里,”他告诉Jeroen,“坏消息是,我把问题定位到了一个数据库SQL上。”
得知这位同事对数据库问题并不是很有兴趣,Jeroen说愿意提供帮助。在回复中,Jeroen收到了下面这张图片。
“我想没人能帮得了我,”他的同事写道。
图片里不是一条SQL命令吧?如果一条能写这么长就太恐怖了。
觉得是个存储过程还容易让人觉得可以理解
有sql脚本格式化工具可以帮助理解
我相信这种玩意儿的存在。
对sql用的少,于是将上图等价变换为一个一个C++函数…顿时感觉鸭梨无比无比无比无比巨大,这位同事,祝你好运!
OMG,真的有这么长的SQL啊
我见过一页纸的SQL,没见过这么长的。
是不是把整个数据库的表都给用上了。。。
我想是
写出这条SQL的人的逻辑得多厉害啊!
这有点夸张了,是程序自动生成的吗?如果不是的话,是太恼火了….
相当NB!
悲剧……
这种sql
可维护性太差了吧
我见过一个SQL,128页也没有显示下,到底多长只有天知道。
这样的sql估计运行起来也慢到要死吧
见过3000行的SQL飘过
我见过最长的SQL语句也不过是包含400多个字段,比起这个应该还差点。
相当可以了。
遇到这个,我宁可挪屁股换个公司
上帝啊。。维护这段程序会疯掉的
只写过2000+行的。
在导出数据库的时候见了N长的SQL,但这也是只是插入数据而已.
我朋友给我发个他们公司写的SQL,是格式化好的,记得也就1000行吧!
重新开发这个老程序吧!HOHO
见过一条sql有24KB的超级恐怖
幸亏我们用NoSQL
看来我最近写的4k的sql算简单的啊!
读这种SQL简直就是在考研程序员的二级缓存大小,缓存小的就不行了,要不就得有强大的内存调用管理机制,能够将整个逻辑分开来,逐个检查,老外一般喜欢把东西分开做,国人一般喜欢混沌处理,凭借强大的二级缓存,曾经我也属于后者;
当然,这仅仅是我的看法;
写这SQL的人也太NB了
写这个SQL的人根本不NB= =这语句不是会导致bug么= =
写出这脚本的人难道真觉得这脚本不会有bug吗……