用一个 alias 字段索引进去就可以了，也不需要 or，因为本身就是 fulltext

存拼音不就可以了吗

nokogiri 就支持 css 选择器

update_attributes 不是消息？不是接口？

我看到你讲别的技术话题的时候还是有可取之处的

之前看到楼主在一个帖子说「一般网站不需要考虑一致性，丢些数据也是可以容忍的，半夜关站跑脚本备份就可以」，我就觉得吧没法讨论的，他非要把范围限制到一个很狭隘的领域，既然这样自己喜欢自己用去咯，还有什么值得讨论的。

https://ruby-china.org/topics/16995

windows？我看你就是在为难我胖虎！

可以很快的

遇到 PM 这样提需求，我一般都回「你把需求想法描述清楚，或者给一个可以抄的网站看看」

粗暴

很少听说过压工资的互联网公司…

Yes.

对于简单场景，用 ORM 来做 reporting 也是可行的。对复杂场景，不能说 AR 抽象程度不够，本质上每个 gem 有自己的解决的领域。

# Sam: complicated reports are really hard in AR

代码重复问题，其实这就是一个 tradeoff，ORM 里的方法对于 reporting 来说，理论上确实可以共用，但实现上是很难共用，硬要共用的话，必然是写成 N+1 的方式，之前做过一个项目，reporting 部分就是这种思路写的，数据量还不大的时候一个页面就可以达到几十秒。

如果 reporting 部分想共用的话，其实需要写 UDF 和 view，试过几次效果还不错。

刚看了这篇文章，mini sql 的用途写的非常清晰了：https://meta.discourse.org/t/new-official-direct-sql-access-api-for-discourse-mini-sql/90441

 # Sam: complicated reports are really hard in AR
 builder = DB.build <<-SQL
SELECT ftl.url,
       COALESCE(ft.title, ftl.title) AS title,
       ftl.link_topic_id,
       ftl.reflection,
       ftl.internal,
       ftl.domain,
       MIN(ftl.user_id) AS user_id,
       SUM(clicks) AS clicks
FROM topic_links AS ftl
LEFT JOIN topics AS ft ON ftl.link_topic_id = ft.id
LEFT JOIN categories AS c ON c.id = ft.category_id
/*where*/
GROUP BY ftl.url, ft.title, ftl.title, ftl.link_topic_id, ftl.reflection, ftl.internal, ftl.domain
ORDER BY clicks DESC, count(*) DESC
LIMIT 50
SQL

 builder.where('ftl.topic_id = :topic_id', topic_id: topic_id)

这个确实很有用，之前用 Rails 做项目遇到统计需求很尴尬，用 AR 来做特别难，一般最终结果就写成了 sql+rails 的合体，导致可维护性特别差。

本质上是统计需求和 ORM 并不是同一个维度上的事情，ORM 解决的是表和对象之间的关系，而统计需求其实是面向主题的。 另外一个问题是 ORM 做统计的话经常会产生 N+1 查询。所以统计需求我一般都直接纯 sql 的方式来写，不使用任何 AR 相关 API，例如：

AR.connection.execute(<<-SQL)
  /* 按SKU分组，计算出出仓数量 */
  WITH shipment_items_by_sku AS (
      SELECT product_variant_id, SUM(quantity) AS ship_count
        FROM shipment_items
       WHERE deleted_at IS NULL AND company_id = 1
    GROUP BY 1
  ),
  /* 按SKU分组，计算出订单数量、最大金额等 */
  order_items_by_sku AS (
    SELECT pv.company_id,
           oi.product_variant_id,
           sum(oi.quantity)   AS order_count,
           sum(oi.sum_price)  AS sum_money,
           max(oi.price)      AS max_money,
           min(oi.price)      AS min_money,
           avg(oi.price)      AS avg_money
      FROM order_items AS oi
           INNER JOIN product_variants AS pv ON pv.id = oi.product_variant_id
     WHERE pv.deleted_at IS NULL AND oi.deleted_at IS NULL AND oi.company_id = 1
  GROUP BY 1,2
  ORDER BY 3 DESC
     LIMIT 10
  )

  SELECT order_items_by_sku.*, 
         coalesce(sibs.ship_count, 0) AS ship_count
    FROM order_items_by_sku
         LEFT JOIN shipment_items_by_sku AS sibs ON order_items_by_sku.product_variant_id = sibs.product_variant_id
ORDER BY order_items_by_sku.order_count DESC
SQL

但这么写的话带来一个问题，用户传参的地方需要自己去防止 sql 注入，不过 mini sql 的出现解决了 sql 注入问题（使用的 prepared statment），我觉得 mini sql 当然不是去和 ORM 比，其实是弥补了 ORM 在统计和 ETL 领域的不足。看了一下 mini sql 在 discourse 的应用，也是用来做统计相关：

• https://github.com/discourse/discourse/blob/5f64fd0a217552d1e031a28732a0e6000b090cc4/app/jobs/onceoff/init_category_tag_stats.rb#L6
• https://meta.discourse.org/t/new-official-direct-sql-access-api-for-discourse-mini-sql/90441

这个结论怎么得来的，之前用 alpine 跑 sidekiq 内存涨的还是飞快的

卧槽 还作诗

所以女朋友是 HR？

继续继续

不是 6 月 15 日发工资嘛，今天 17 号了，该发多少发多少就完了呗

有多大 响应时间要求多少

tig 算 gui 么

厉害啊

实例变量这样写 @worker 否则会变成 link

没用过 git gui

这波操作 6

俄国人厉害

别闹

都忘了

收到

发个简历看看