从一个小案例看数据库的复杂性

有一个同学问我，OceanBase 里的 upper、lower 函数怎么没有像 ClickHouse 里面这样，一个位运算搞定全部：

我翻了一下代码（src/sql/engine/expr/ob_expr_lower.cpp，src/sql/engine/expr/ob_expr_upper.cpp)，OceanBase 里的实现的确要复杂得多，最后调用了 ObCharset::caseup、ObCharset::casedn 接口来实现转换。顾名思义，OceanBase 做大小写转换时考虑了字符集。

我们通常理解的大小写转换是 26 个英文字母的转换，而实际上有大小写转换需求的字符，远不止 26 个英文字母。比如希腊字母，β -> B, γ->Γ：

OceanBase(admin@test)>select upper('β');
+-------------+
| upper('β')  |
+-------------+
| Β           |
+-------------+
1 row in set (0.003 sec)

OceanBase(admin@test)>select upper('γ');
+-------------+
| upper('γ')  |
+-------------+
| Γ           |
+-------------+
1 row in set (0.004 sec)

OceanBase(admin@test)>select lower('B');
+------------+
| lower('B') |
+------------+
| b          |
+------------+
1 row in set (0.003 sec)

OceanBase(admin@test)>select lower('β');
+-------------+
| lower('β')  |
+-------------+
| β           |
+-------------+
1 row in set (0.002 sec)

反观 ClickHouse，则没有对此做支持：

在2010年，数据库还是一个高门槛的行业。但时间到达2023年，数据库的入门门槛已经非常低了，几个人的团队只需要一两年的时间就可以拿出一个基本可用的产品出来。但是，真正的商业数据库，依然拥有很高的壁垒，体现在方方面面的细节之中，这些细节历经数年打磨，形成隐形壁垒。不过，这些细节问题，并不是每个消费者都会遇到，所以其价值在平时并不能被定价。这也是为什么传统数据库在各个领域常常被颠覆的原因。