真是 100 行不到的你直接说需求，足够有趣的话可能这里就顺手给你写了，不用那么麻烦……

@uyhyygyug1234 #38 但是路上并不是只有你们两辆车。你不超车别人也会超，然后并到你前面，你就得再落后一个身位；这样的多了，你就落下一个路口，中间还得时不时踩个刹车。

@tutustream #3 你的工作是光之快递

@charlie21 #69 你这个说法是挺骚的。但是同理，其他各种乱七八糟的渠道也不应该被说成不合规不正规不正经了。大家都是和开发商签了协议的，价格还特别低，真是棒棒的。

第二种开销大啊。你反复查询数据库都是有开销的，不要以为只是简单的 select 就没成本了。建立连接，解析语句，以及数据的传输，都有成本。

@dzmcs #5 那至少得 bigint 了。单 int 是不够用的。也可以考虑用 decimal 或者 numeric，这俩本身也是同一回事。帐配不平的事情是不存在的，不用多虑。帐要是不平，肯定是你们程序自己出了问题，而不是 decimal 的数据类型问题。

什么数据库？整型是多长？

这俩本身没有什么实质差别。用 Decimal 更方便一些。

所以已读功能是刚需啊。

不会次次删，但是隔段时间会删一次。变动太频繁的时候今天删明天加，就算有版本控制也很烦；隔段时间删一删，保持代码基本可控就行了。

还能这样操作？？？楼主你是公司老板吗

@otakustay #16 第二条就不对。假如表里就 1000 条数据，现在要取 1000 条出来。走索引要多一步，只会更慢不会更快。

@Marstin #52 我也觉得你对他的业务逻辑的质疑是很有道理的哈。qq 这里，我推测它是存在一个人有多个 qq 的情况，然后存一个字段里了，甚至这个字段可能还夹了别的不相干的文本内容，而 qq 的不同位数的问题它又没考虑进去。

主要还是信不过交易所啊。

是的。V2 主流就是前端了，SQL 都基本不怎么会的。


@murmur #1 1-31 的那个处理不过就是个行转列罢了。它希望做出来的结果里，一个人就一条记录，记录里能有每一天的 KPI 和一个汇总值。

@Marstin #42 我觉得你没完全看懂。它是 left join，ahh 里的数据是不能丢的，每条都要，不可以加 where 过滤的。同理，交换 left join 两边的表也是不可行的，直接把业务逻辑都改了。

杭州的社保不用在意，落户难度基本为 0，断了也没啥，重新开始算也不耽误事。

我觉得你也是这号人啊……

怎么赚钱？靠差价啊…… （感觉是句废话）