直接说不方便就好了。

这个事情从两方面看，分给你的需求 是否重要？值得继续做？
如果是，建议做，虽无加薪，但的确升职了，也给你招人管人的权力，也是一个实实在在的锻炼机会。
如果否，而你目前又急需钱，是可以考虑走。

慎重吧，不要只听上面的人一句话建议。

如果组织者 是想认真做一件事情，那么基本是不可行的。前面有人解释过了，没毕业的学生基本都是三分钟热度，况且还是没收入的事情，不可能长久的，真想要做事情，自己先行，做好一期后，展示出来，有志同道合的人会来找你。 不要找学生或者是刚毕业的。

不能选择节点？

营造一个办公环境，不然不要在家办公

女儿的问题是其次，思考跟你结婚的这个女人是否还值得继续下去，因为还要一起度过几十年，如果不值得，请考虑离婚。一个人也能带女儿。

好看的皮囊千篇一律

小问题， 先把原型画出来。

5L 讲得没毛病，你想想假如你的程序 1w 行代码有 9999 个空行，只有一句 print，编译器难道不会过滤空行吗。当然了，这是举个栗子。还有深层次的优化；再举个例子，A 和 B 两种代码样式最终可能用更简洁效率的 C 样式完成， 那编译器当然会优化为 C，这个时候当然不可能推断出原来的写法。

Java 学两个月，go 学 20 天

建议添加目录

一个小康家庭在大城市问自家属于哪个阶级

你应该是要饿死了

都有家庭了，还能想干就干？开启一家老小上海租房之路？

描绘...态度？

卧槽，删除都不提示一下的？

@nightspirit 我写的应该足够清晰，你可以在读一遍; user 表是否再分表也是没关系的。

年轻，这说到底是你的竞争力不够。如果你手握几个 offer，还有的她甩脸子

还是没太看懂描述，说说我的理解：
1. 用户要在一页内显示完所有的订单（不分页？）
答：个人觉得可以在(user_order_ref)表内存储 uid 和 order_id_list 的关联关系，order_id_list 字段是 json 数组，mysql/mongodb 都可以容易的做 json 对象的操作，那么这张表的数据量就<=user 表，不会太大，也就不需要分表，那么这里就可以拿到用户所有的订单 id 。 （有的人也许会考虑部分 rows 的 order_id_list 字段过长带来的一些对表空间的影响，其实我认为可以忽略，因为一个用户的订单量上天了也不过几千几万，这点量不会有什么影响）
然后就像楼主说的，订单详情表使用订单 id 做 hash 水平分表，这里就能查到一个用户所有的订单详情了。
2. 司机的 APP 也能显示订单
答：司机 APP 显示自己的订单，其实与用户订单没啥不同，按照前面的做法，是可以实现按排序分页的（计算出要读哪些订单表，然后 union+orderby ）。

个人愚见。