有一个设计的不同：PC 的列表翻页，上一页和下一页可能重复，一般都觉得正常，而手机的的翻页属于下滑翻页，如果有重复了就很别扭。

个人认为，广州最适合。
惠州地方太大，人少，几乎不增值（有价无市）；
东莞的房价也不便宜了，市区 3 万+；
中山，天天过去么？深中通道也不便宜；

广州，教育、医疗比深圳好，而且非常适合居住，房价没有深圳贵，至少跳一跳还能够得着

如果有时间的话，可以实地去碰碰运气，可以找保安问问有没有空缺的。

另外，其实不建议住低楼层，湿气较大、蚊虫也多，找个带电梯的中高层好点。

搞不懂为什么这么多人求 star,,, star 多了有什么用？

@GetMapping("/demo0")
@JSON("no,name,age,zoo(name,address,city(id,name))")
只会返回 no 、name 、age 以及 zoo 对象里面的 name 、address，以及 zoo 下面的 city 里面的 id 、name


@GetMapping("/demo1")
@JSON("no,name,zoo(name)")
只会返回 no 、name 以及 zoo 对象里面的 name


@GetMapping("/demo2")
@JSON("no,name")
只会返回 no 、name

如果是 java 系的话，可以试试这个库 https://github.com/ksprider/Surgical

@newtype0092 ES 也可以做的。只是单纯的数据库(比如 mysql)查询对于大多数开发者来说上手最快。

我上面说的第三种指的是，把多个业务库的只读库放在同一个实例里面，单纯的用于查询（业务、一般的报表都可以）。

我个人倾向这种做法。

好问题。我也经常拿这个问题来面试。
正如#17 所说，「千万别把查询做成了数据统计」，但是在实际中很难(也懒得去分太清楚)查询和统计之间的边界，据我接触的需求来看，一开始订单列表包含商品，进而包括卖家信息，再包括买家信息，后续可能包括其他的信息等，所以这样的需求一般情况下是逐步的迭代形成的。

我个人有以下思路：
1. 和#5 一样
这样好处是不用考虑商品表结构变化(前提是商品服务不是由你维护)，坏处是写 n 多代码

2. 放到数据仓库里面去查询，例如 es 里面
坏处是要搭建 es，使用成本有点高

3. 新开一个数据库实例，将用户库、订单库、商品库同步到这个实例里面，做跨库查询（具体同步的技术可以用 canal 、DTS，实在不行，自己用 mq 解决）
坏处是要维护表结构的同步，且需要了解基本的业务（例如哪个字段代表什么意思之类的），好处是查询起来很爽很爽

kotlin 用 exposed，java 用 jooq

compile "com.fasterxml.jackson.module:jackson-module-kotlin"

既然用了 kotlin，exposed 不香吗？（不喜欢 mybatis ）

南山医院验光，在天猫上买的明月眼镜，陈道明同款

做什么方向的

@syun0216 电动车一大把，去店里面看你喜欢的随便挑。建议买个小巧点的，老腾讯大厦那边经常有便衣抓摩的，太大的话容易被误认为摩的。

@syun0216 公交的话 m425 吧，很多人。电动车走人行道，很方便，上下班高峰期有时候比公交还快些。