@icetomoyo 关注细节是技术人员的美德。连细节都不关注，还能做个什么？说是懒得纠结这种问题，结果你还是点进来了，不光看了，还回帖了。不争强好胜那你就认个错呗，你死扛着不认，不就是争强好胜？

还分场景…… 你是逻辑也不好吧，真值表会不？

@icetomoyo 别急着互相吹捧，先把为什么不能用中文注释讲清楚。讲不清楚就认个错，不丢人。

太浪费别人时间了。性别和大公司经验什么的，一看简历就知道了，何必还一面二面三面。直接一开始就不招，别人一句话都不会说。

@t86 为什么不能用中文注释？我还偶尔用中文变量名呢。

@loryyang 所以问人也是很合理的嘛。贴个百度搜索第一页，能表示个啥？表示只要百度上有就可以随便用？

看人生阶段啊。年轻的时候时间不值钱，能换点钱是最好的。

又不是网上随便搜个东西就能用的。网上搜的东西，一要看是不是真能解决问题，二要看是不是适合当前场景，三要看是不是能融入到现有项目中去，四要看是不是有更好的选择。
我曾经接手过一份代码，几乎做每件事情都用了 N 套不同的方法。这个文件里是这么做的，那个文件里那么写的，全部看完都觉得大开眼界，有效培养了发散思维能力。想来多半是各个功能的作者都自己独自从网上搜过来写进代码里的吧。请问你喜欢维护这样的项目吗？

@suikatw 存储过程也是代码，代码怎么做版本管理，存储过程就怎么做管理。把存储过程弄到生产数据库里编译，那是代码发布的阶段了。

@labasq 视图没什么缺点。但是对于加快你的查询速度毫无不相干。

我觉得按你这要求还是自己定向培养比较好。外面的没几个能长得这么吻合的。

@labasq 别听嚷嚷着视图的人瞎扯…

@zacard 那只是你们的开发手册。要说逻辑复杂，金融, 电信，这两个行业是 sql 使用的重灾区，难道属于业务逻辑简单的类型？

@jsou 业务逻辑放外面也就分布式上占点优势，其他谈不上特别的好处，反而是开发人员自身背景和偏好的影响更大些。

这东西得看，不能一概而论。跟业务，跟数据库本身，都有一些关系。

@konakona 子查询和 left join 又不等价，你是怎么拿到一块去比的？

@shijingshijing 你需要了解一下数据库的优化器。

摩拜这周免费了

我觉得这个简历可改的地方很多… 要突出重点啊，多用可量化的数字。开头最上面那句让人觉得莫名其妙，删掉为好。后面遇到的问题和解决方法也没必要写，又不是什么特别值得一提的成就，简历写这东西做啥…

当然被 HR 无视也不完全是简历怎么写的关系。再怎么美化也不能违背事实嘛。你的毕业院校和工作经历可能要背更大的锅。这个也没办法，找工作有时候也得看缘了。

Databases are born to join.