{} 跟 do ... end 的区别只在于跟前面的方法结合的优先级，简单来说 {} 会 “紧贴” 它前面的方法，而 do ... end 更加宽松。

我看楼主之前有过几个帖子讨论语言的设计优劣问题。但说实话纠结这些并没有太多意义，更多是结合个人偏好的主观问题。倒不如多了解下各种语法的客观差异，避免踩坑，然后总结出一套符合自己偏好的编程方式和风格干活。

确实 query plan 不同，感觉 CTE 更严格的按照每一步去划分优化的边界，而子查询作为一个整体查询有时候会优化得更多一点。所以我一般是测试时写 CTE 然后转到代码里再换成子查询。这样也更容易转换成 app 层的代码。因为 Elixir 的 Ecto 可以写出非常复杂的分析型查询，但目前还不支持 CTE 。

Emacs 有个插件能帮你对齐，也是你说的 river 风格。不过 Emacs 的对齐功能基本都有点自恋 + 死不认错，人工调整后编辑器也会不停的帮你 “纠正” 过来。想调整规则得去研究类似 AST 的数据结构，所以我直接放弃了……

缩进方式很有意思。这个例子还是很考究的，比如 JOIN 其实是属于 FROM clause 的部分，算是 FROM 下一层的表达式，因此缩进在 FROM 的更右边，ON 下面换行的 AND 同理。

这种方式我尝试过一段时间（可能不是严格照着这个 styleguide 来的）。最大的感受是必须有编辑器提供自动格式化才好用，几乎没办法靠人工维护。尤其是写超过 20 行的话自己都不知道缩进对不对，每多加一行都可能导致之前写的部分重新缩进。

PostgreSQL 文档里有些 SQL 例子是按这种方式缩进的，但也有混用的。比如 window function 的一个例子，内层按分界缩进外层就顶头了：

SELECT depname, empno, salary, enroll_date
FROM
  (SELECT depname, empno, salary, enroll_date,
          rank() OVER (PARTITION BY depname ORDER BY salary DESC, empno) AS pos
     FROM empsalary
  ) AS ss
WHERE pos < 3;

DRY 的代码特点是 “改了一个地方，所有相关的地方都被影响” 。有时候这是好事，另一些时候则是坏事。我觉得用 reason to change 来衡量代码是否需要可重用是个可行的做法。如果两段代码实现相同，但是为了不同的业务目的，那就让它重复。

另外也赞同接口设计比实现更重要。接口定义得良好，实现烂一点影响范围也有限，并且容易重构过来。个人感觉过度重视局部代码的精巧结构，以 DRY 为主要的衡量指标，甚至以实现来反过来影响接口设计是很多新手常犯的错误。

@chenge ROM 里借鉴了 Changeset 的概念 ：https://api.rom-rb.org/rom/ROM/Changeset.html

Rails 的 ActiveRecord 作为一个超级 model ，在框架层面集成好用的功能于一身。这点跟 Ecto 在设计理念上有根本差异，脱离这点谈 Changeset 不大现实。毕竟 Changeset 的所有功能在 AR 里都有，只是如何组织，以及好不好用的问题。无端添加一个概念反而容易让人迷惑 -- 我该用那种方式修改数据？这点在 Ecto 里并不存在，因为 Changeset 是唯一修改 “模型” 数据的方式。

Changeset 另一个好处是容易脱离数据模型再开一层抽象，比如做外部数据的校验。这方面其实 Ruby 也早就探索过，不过是叫做 Form Object 。虽然 ActiveModel 不太给力，但 Ruby 社区的轮子也不少，不喜欢 AR 的可以去用 dry-rb ，有相对完善的校验和类型系统，足够你干很多事情。

名词是新名词，但内部概念还真不是新概念。

@chenge 建议从 Ecto + PostgreSQL 搭配入手。Ecto 对它的支持最好。

没看懂你要的计算逻辑，好歹也表达清楚点吧？

嗯，就是延迟反序列化的过程，这里的 pg 也是说的 Ruby 库，跟 PostgreSQL 本身没什么关系。

PG::Result stores values received from the database internally in a compact memory format. When the value is accessed, it is converted to a ruby string or casted to another ruby object.

不考虑数据量问题的话，就一个简单的 reduce ：

require 'csv'

CSV.foreach("data.csv", headers: true).reduce({}) do |acc, row|
  priority = row["优先级"]
  acc[priority] = (acc[priority] || 0) + 1
  acc
end

如果量大并且需要跟其他表结合做统计，导入数据库是更合适的选择。除了用 COPY 外 Foreign Data Wrapper 也可以考虑，简单粗暴。

老实说，不会。原因几点：

1. 越是受众面不广的技术越要跟国外的一手资料。一般来说订阅 Elixir Radar 并定期逛逛 Elixir Forum 足矣。而且像 @Rei 所说 周边的书也已经不少了。

2. 国内资料太少，考虑到实效性就更少了。因此我一般不会选择看中文的（即使搜索到）。我想近几年愿意吃螃蟹学习 Elixir 的人大多也是这个习惯。所以中文资料就更难有市场。这确实是个恶性循环，但任何圈子的形成都是需要时间的。大部分时候我们是要解决问题，那就得用更有效率的获取知识的方式。