hashid

是

• pg 的主键和二级索引是没有区别的，都直接指向磁盘的一个位置
• mysql innodb 的主键和二级索引是有区别的，通过二级索引查询先找到主键，主键再找磁盘位置；二级索引上是会冗余主键值的。

所以 mysql 在主键查询场景优于 pg；pg 在二级索引查询场景优于 mysql

1. UUID + MySQL 的话，数据迁移是灾难，虽然数据迁移的概率很低，但估计要比迁移到分布式数据库发生的概率高很多
2. UUID + InnoDB 索引膨胀，因为 InnoDB 的二级索引是指向主键的，就是多一条二级索引就膨胀一些，当然还有 buffer pool 和磁盘之类一定也膨胀

所以选不选 uuid 是一个技术层面的需求，和你使用具体的 DB 直接相关。而业务相关的需求完全可以通过其他手段解决，比如 https://github.com/namick/obfuscate_id 你完全可以使用 bigint，然后暴露给外部 string，再反向解析回来。退一步讲，真的有分布式需求或者客户端同步需求，从 bigint 往 UUID 迁移也是容易的。

https://ossinsight.io/collections/web-framework/trends/?historical-trending=pr-creators&historical-rankings=pr-creators&bar-chart-race=pr-creators

从 PR 和 Contributer 角度看 rails 还是第一

流量多少可以收这么多

用什么工具画的

先把头像换了

pghero 更好用一些

中文是另一个问题 估计是 locate 没配置对

商业互吹而已

Rails7 对 Tailwind CSS 主力支持，但是这个东西是 laravel 社区的人搞出来的。、

只是作者会一点 php 吧？这也能蹭

感觉问题不大

内存爆了。。

随便写一个你熟悉的 然后 rubocop

盲猜 storage 没有持久化

是的 但 not in 其实还好，一般都会跟着其他条件一起，还是走索引的，只是再多了一个 filter。 最可怕的是 or 查询，这个才是索引杀手。

马后炮😂

黑名单只是一个便于理解的例子 实际情况可以很复杂 你可以理解为 in+子查询的都会触发

牛啊

我也觉得挺好看 功能很强大 速度也不错

流量吗 现在用的新用户优惠 估计可以白嫖半年

还好吧

所以现在流行什么风格

forem 是 dev.to 开源的，discourse 更偏向论坛，我感觉 dev.to 更偏向是一个博客平台。

discourse 面向用户群体广一些，forem 对开发者友好，很多功能都是针对开发者定制的。

确实可以节省成本 打算下一个应用试试部署到 flyio

我再试一下 刚从一个教程的 demo 代码里这么操作 import 报错 感觉是没有把 node modules 加进去

重新建了一个项目可以了

引入 javascript 库还是用 yarn add 吗 需要额外设置吗

cubejs 用过 体验不是很好 但灵活性确实挺高 plotly dash 看起来和上面发的 link https://observablehq.com/ 有点像 不过我对 pandas 不感兴趣 对于报表类分析需求 SQL 速度快还方便 pandas 大数据处理并不太行