@xulolololololo 这还是个习惯问题。

DynamoDB 的目标很单一，就是快，为了快，它舍弃了很多传统数据库系统提供的功能。

就拿你说的那个排序问题为例，你觉得传统数据库是怎么实现排序的呢？无非也是两种——要么全读出来再在内存中排序，要么用那两个字段建个索引。你现在采取的是“索引法”，如果数据量不大的话，也可以全读出来，然后在内存中对结果执行排序算法。

看，DynamoDB 是不是跟传统数据库一模一样？只是把原先水面以下的东西拿到了水面以上而已。或者说，为了快，舍弃了传统数据库提供的包装。

其实这还算好理解的，个人觉得 DynamoDB 与传统数据库最大的区别在于数据的组合。传统上我们会用多表 join，但 DynamoDB 不好 join，只能多次查询。这让习惯传统的程序员很难受，如果你们公司有 code review 的话，一定被骂过查询太多，要求优化。

但 DynamoDB 不一样，因为它快，而且是 serverless 。这意味着我们可以同时发起成百上千个查询请求，让成百上千台服务器同时给我们干活。比如你要想把订单和用户信息组合在一起，那就先查订单，然后用异步 /协程 /多线程去同时查询这些订单里的用户 id 。不用怕，这比传统 join 还快，关键是不会形成瓶颈，就算某个查询慢了，也不会占着资源影响其它人。

AWS 深度用户路过，没用过阿里云的对应服务，但 AWS 的 Serverless （ Lambda+DynamoDB+APIGateway ）很对我胃口。

一开始确实如楼主所说，不符合传统开发习惯，但习惯以后再做传统项目，就觉得这也不爽那也不爽。所以这只是个习惯问题，没什么好坏之分。

不过没什么好坏之分是指的开发，若需要开发兼运维，那还是 Serverless 爽。尤其是云服务器，访问量稍微一大，就开始各种各样奇怪的毛病，很多是云服务器低下的 IO 性能，甚至是低配服务器被母鸡故意闲置资源所致。而 Serverless 就没有这些，还省个运维的人工成本（程序员免费加班兼任运维工作的那种公司不适用）

新建一个 userid 表，第一列是原始 id，第二列是目标 id，默认情况下两列一样，合并后的就不一样了。

查询时 join 这张表。

试试英文短信，我知道有些中文短信 gv 是收不到的，不知 fi 是否也这样

严格来说，你在哪里换汇，就用哪里的汇率，爬也好买也好，必须用你真正可用的那个汇率。

为啥呢？因为各金融机构之间的汇率差太大了。尤其是跨国，你在中国换美元与在美国换美元价格差了不是一点半点。

根本不洗稿，人家都注明出处的，只是没有授权，不让爬硬爬而已。
实习生确实有很多，但不是洗稿用的，而是给文章打 tag 的，否则怎么按兴趣推荐？

怕是连公司的局域网都要负责维护吧

几个月就能练出来的话，说明你底子已经很好了。可以注册个 toptal 面试一下试试

用了好几年云数据库，已经不知道该怎么选配置硬件了。

嗯……其实软件也不用配置，都是 managed service，拿来即用

实际上传指针才是主流，PHP 那种默认传值，加了&才传指针的，属于少数派

@whisky221 同意，吃亏吃多了就老实了，我现在一些特简单的功能也要调包，有时花的时间比直接写还要多一点，但可靠更重要

问：有人溺水了，请问如何抢救？
答：请看《如何才能不溺水》

26 楼 @xiangyuecn 和 30 楼 @craig 打一架吧，我看热闹不嫌事大

推荐 JS （准确的说是 TypeScript ），这玩意入门容易、生态完整，做个调包党很快就能产出。

你要想做深度，JS 也能满足你，它虽然入门容易，但并不像没有真正拿 JS 当过主力语言的人说的那么不堪，认真研究起来也不是简单的。

而且 JS 发展很快，一直在吸收其他语言的优点（比如 C#的 async 和 await ）。你还可以拿 JS 试试函数式编程，绝对是开拓思路的一种玩法，传统程序员被 Java 毒害太深了，连 PHP 都 Java 化了。

本来人家只想临时爽爽，你说先把彩礼付了吧吧，如果需要可以再改成按次付费的