『 SQLite 测试通过（排版原因，每行代码开头有 _ 和 全角空格）』

WITH
　 orig_data(class, stu, course) AS (
　　 VALUES
　　　('1 班', '学生甲', '语文'), ('2 班', '戊', '语文'), ('3 班', '辛', '语文'),
　　　('1 班', '学生乙', '语文'), ('2 班', '己', '语文'), ('3 班', '壬', '数学'),
　　　('1 班', '学生丙', '数学'), ('2 班', '庚', '数学'), ('3 班', '癸', '数学'),
　　　('1 班', '学生丁', '数学')
　),

　 table_with_rank(class, course, rank) AS (
　　 SELECT class, course, RANK() OVER (PARTITION BY class ORDER BY COUNT(*) DESC) rank
　　　 FROM orig_data
_　　 GROUP BY class, course
　)

SELECT class, GROUP_CONCAT(course) courses
　 FROM table_with_rank
_WHERE rank = 1
_GROUP BY class


『结果（可能出现多个并列第一的课程，此时用「,」分隔）』

class 　 courses
-----　-------
　 1 班　语文,数学
　 2 班　语文
　 3 班　数学

@HankLu 你可以去问问 @churchill ，毕竟 js 是世界上最好的语言，写出来的代码有着 O(1/N) 复杂度，区区一个大文件算得了什么，某些机构对世界的监控就是用 js 做搜索的

@churchill 嗯，我痛心疾首

那 21 楼会让你如丧考妣

@churchill 感觉就像娱乐圈明星某些粉丝的行为，别人讨论点不相干的啥都来踩一脚。。

“我家 xxx 最棒！”

我不是哪个语言的粉，有更合适的就学着用

@HankLu 其他帖子有大佬说过，Python 的 in 用了介于 Boyer-Moore 和 Horspool 之间的算法，比 KMP 快

还不满足的话，你可以问问 @xgdgsc #16 ，

按他说法，那个啥语言随便起来比 Python 快几个数量级（假设 3 个），那严肃起来还要再快 1~2 个

有个排行榜说，C/C++ 比 Python 快 2 个数量级，

综合算下来，那个啥语言严肃地写，可以比 C/C++ 快 1~3 个数量级

@houzhiqiang 嗯？我第一眼看你 17 楼，以为 v8 比 pypy 快一倍，比 cpython 快五倍呢，

原来你是用了 少一个数量级 那个代码啊。。

@houzhiqiang 看起来日用差距不大，真要求性能，还是上 C/C++ 之类的吧，wasm 都没用（比如 squoosh 转码 avif ，比本地 avifenc 慢太多）

@xgdgsc 不会吧，就算那个测评榜，C/C++ 之类也就比 Python 快两个数量级，你这啥能 3+ 个？

@wyc9296 你把 str(i)+'->' 改成 f'{i}->' 应该还能再快些

不是一堆人把数据库当 kv 用的吗？那么多功能对他们有啥用？

这个例子中，Google 花这么多钱搞的 V8 ，也没甩开 Python 多少啊？

这 8 楼 9 楼（ 9 楼还少了个数量级）和楼主的没 JIT 的 Python 一比（第一个例子改成 += 就好），也没快多少啊

你换成 a += str(i)+'->' 就差不多一样了

s='HELLO|*.py'
IFS='|' read -ar arr <<<$s

『 declare -p arr 后输出』
declare -a arr=([0]="HELLO" [1]="*.py")

假设按行分割，不要求按顺序输出的话：

sort a b | uniq -u > c

手机充电后，还会用电池的电吗？

@LeegoYih 这数据量小，可能都缓存至内存了也说不定

有试过每张表的 B+树三 /四 /五层高（视行记录长度的不同，可能分别能容纳几千万、几百亿、几十兆行记录）时，俩 /仨表 join 的耗时差异吗？

@LeegoYih 数据库范式是有点理想化，

所以，若有性能（你 join 多一个表，肯定性能差些）、分库分表难 join 等实际问题，你会妥协地加入『部门 ID 』至『用户表』吗？

就再打一两周试试呗，反正要耗的精力不像五笔那么大

@LeegoYih 数据库新手说下看法，有不对的请指正


这是另外一种什么范式吗？


以前学过的数据库范式说，

1. 每个字段都必须是不可再分割的原子数据项，不能是集合、数组、另一行记录等

2. 其他字段必须完全依赖整个主键组（如：用户部门表『「用户 ID ，部门 ID 」，用户名，省份名』，用户名只依赖用户 ID ，省份名不依赖任何其他字段，故不符）

3. 非主键不依赖其他非主键（如：学生表『「学号」，学院 ID ，学院名称』，学院名称依赖学院 ID ，故不符）

然而实际出于性能、分库分表难 join 等原因，总会冗余一些字段


回到你的回复，你说 用户表『「用户 ID 」，……，部门 ID 』不妥，

1. 部门 ID 业务不依赖 用户 ID （是说违反第二范式？但感觉实际上是依赖的？用户所属部门？）

2. 或用户可所属多个部门（部门 IDs ？但这违反第一范式？）


总的看起来，感觉你像是在说违反了数据库范式

所以，若有性能（你 join 多一个表，肯定性能差些）、分库分表难 join 等问题，你会妥协地加入『部门 ID 』？