这就是为什么你几乎总是需要手动指定索引的原因，而且这种索引需要数据库“内部支持”。你一次又一次的希望 SQL 能够自动为你生成高效的索引和算法，却一次又一次的失望，也就是这个原因。当然，你永远可以使用所谓的 stored procedure 来扩展你的数据库，然而这就像是我的 IU 同学们用 miniKanren 来实现 HM 类型系统的方式——他们总是先使用一种过程式语言（Scheme）来添加这种描述性语言的“相关特性”，然后欢呼：“哇，miniKanren 解决了这个问题！”而其实呢，还不如直接使用过程式语言来得直接和容易。

首先“过程式语言（Scheme）” 我记得你自己之前好像喷过部分 Haskell 民『Scheme 不是函数式』言论的，显然 R6RS、Racket 这类 Scheme 都可以使用过程式的方法编程，但一般都认为它们更像函数式
然后你说的描述性语言是指使用 Hindley-Milner polymorphic type system 的 Haskell 吗？可 Haskell 真的不是逻辑式吧...
后半句的逻辑完全是冲突的，而且 miniKanren 这种类似自动定理证明器的东西（虽然我不了解）明显会比纯过程式编写类型检查器推导器上会强很多（比如，它就可以描述某个未知量 t 的类型符合 HM 的类型约束，而不是手写检查算法过程），因为它长得和形式化逻辑系统很像。

而其实，数据结构的理论，可以很容易的解释所有关系式数据库里面的操作

肯定的啊，因为都是现代的计算机来执行，数据结构肯定比关系型数据库要广。

每一个“foreign key”，其实就是一个指针

差不多，但回答者也给了个补充：更接近于一个”reference“，而不是 C 的 Pointer
何况还有 ON DELETE CASCADE 呢，它就更像是完整的对象引用了

在实现上，join跟指针引用有一定差别，因为 join需要查“索引”（index），所以它比指针引用要慢。

JOIN 只是指明了抽象语义！（划重点）
即便你说是在实现上，你讨论的也太泛泛了

所谓的查询（query），本质上就是函数式语言里面的filter, map等操作。只不过关系式代数更加笨拙，组合能力很弱。

这就是 SQL 的需求，若是单单这些『组合能力』能一手遮天，那为啥没人用 Python 写 SQL 解释器？为了性能和现实世界不可避免的东西抛弃『组合性』『重用』的例子比比皆是，比如现在的人工神经网络组成粒度问题，（如果用 OOP 方法设计）肯定没有人会“灵活”到每个神经元一个对象吧。

[sin(1/x) for x in xs if x > 0]


[sin (1/x) | x <- xs, x > 0]
  where xs = [-100..200]

这 Python, Haskell 的 List comprehension 算不算组合能力弱，可偏偏还是有人用

由于“行”只能有固定的宽度，所以导致了你没法在里面放进任何“变长”的对象

这就不对了，比如 Lua 吧，你是不是可以说，因为 Lua 的 union Value （它是 CommonHeader(struct GCObject) 和 ByCopy objects 的 Product type，具名融合结构体，或者叫结构体）只有固定的长度 size_t
就不能利用 Typed value struct TValue 来依照 tag 解释它的值是『指针』呢，还是 fixed size 呢？
就像 Rust 里也有 DSTs，Dynamic sized types 的支持一样，就是使用 slice fat pointer 实现的，为什么刚才说数据结构可以解释 Rel DB，现在又说 DB 是『青出于蓝而菜于蓝』

比如，如果你有一个数组，那你是不能把它放在一个行里的。

即便是数组，甚至 BitMap 也是可以的，没有听说过『指针』（刚才还提到）吗？

你需要把数组拿出来，旋转90度，做成另一个表B。从原来的表A，用一个“foreign key”指向B。这样在表B的每一行，这个key都要被重复一次，产生大量冗余。

这里“旋转九十度”其实是说给它的每个 Key 命同一个名字（用来表示这是一个数组 a 里的值）
然后每次去做 SELECT * FROM B WHERE id=?; （这里 id 是一个『数组』的名字，B 其实可以是一堆数组所有项目组成的表） 这样的操作？
这一点已经是神仙打架了，看不懂原回复，我只负责辅助理解观点。

使用基本的数据结构，其实可以完全的表示关系模型以及被它所“超越”的那些数据模型

废话。

数据模型可以完全被普通的数据结构所表示，然而它们却不可能表达数据结构带有的所有信息

有区别吗？听起来和 ORM 的思想背道而驰，正好 OOP 就是 SP 的数据、操作的融合加上多态。

最早试图冲破关系模型和SQL限制的一种技术，叫做“列模式数据库”（column-based database），比如Vertica, HBase等。

这里复制原回复
Vertica是使用SQL的RDBMS。Column-Store诞生是为了更有效地解决大数据分析的问题（OLAP workloads），节省硬盘I/O（就是所谓列压缩），运用SIMD等等。不知道这和逃脱SQL有什么关系。

很显然，每一个数组需要一个字段来表示它的长度N，剩下的空间用来依次保存每一个元素，这样你只需要一个key就可以找到数组里所有的元素，而不需要把key重复N遍。

c++11 的 std::string 就是类似的实现

Key 的问题的确是关系数据模型的一个问题，因为它（ORM）的确是强行要求关系，然后利用关系查询哪怕是本来可以直接 select where 的，比如，你想“破格”为一些本质上是双向关系（a ~>(type) b）的数据建模，那就得把一个 nosense 的 ID Key 重复 N 遍，非常无聊。

上面的特性称为 random access，随机访问，意味给地址就可以读写数据，不过这里它是在描述一种关系表格

arys:
key | n | seq
'foods' | 3 | ['apple', 'pineapple', 'pen']
'discs' | 2 | ['江南皮革厂倒闭了', '只因你太美']

SELECT n, seq FROM arys WHERE key='foods';

rather than

key | obj
'foods' | 'apple'
'foods' | 'pineapple'
'foods' | 'pen'
'discs' | '江南皮革厂倒闭了'
'discs' | '只因你太美'

SELECT COUNT(obj), obj FROM arys WHERE key='foods';

不要在实际工程中使用这种结构，它是错误的（不一定保证顺序，而且低性能且不符合实际用途）

我这个菜鸡最开始弄 GeekApk 的一些双向关系，比如 user <~(star)~> app 的时候就遇到过。实际上，这不止是 GeekApk 尝试的问题，所有要求动态双边关系的应用程序都得想办法解决，解决方法往往是：把关系也认为是『有地址（id）』的实体(entity)...

CREATE TABLE users(id INT PRIMARY KEY, name Char NOT NULL, nick VarChar);
CREATE TABLE apps(id INT PRIMARY KEY, package Char NOT NULL, name VarChar);

CREATE TABLE relation_user_app_star(id INT PRIMRAY KEY, user INT references users(id), app INT references apps(id));

对这个回答者的回复也有点奇怪
这是什么压缩算法？把字典压缩理解错了？把run-length压缩理解错了？这怎么解决变长问题?
我不知道这和压缩算法有啥关系... 明显只是打算存的数据本身长度缩短了，不过最后一句是对的，照王垠的说法，没法解决变长问题。

其实数据库的问题哪有那么困难，它其实跟“远过程调用”（RPC）没什么两样

又是以偏概全，其实编译原理的问题哪里有那么困难，它和 kotlinc File.kt 有啥不一样？
其实软件逆向工程哪里有什么困难，我 jad ComplexClass.class 就完成了
其实垃圾回收的问题哪里有那么困难，它和“系统自带”的『堆』分配器 malloc() 明明没区别
其实 malloc() 的问题哪里有那么复杂，mmap() 就好了

觉得一个东西很简单甚至等同另一件东西分两种情况：
第一种是你刚入门，对自己似是其非的发现欣喜若狂；第二种是你已经看破人事，游刃有余。
把使用和实现混为一谈的属于第一种情况。

只要你有一个程序语言，你就可以发送这语言的代码，到一个“数据服务器”。服务器接受并执行这代码，对数据进行索引，查询和重构，最后返回结果给客户端

欸，这不就是我开始打算给 GeekApk 加的 Query Combinating Language 吗（Telegram）？看来真是略同、略同（抱拳）。

((<< filter flatten) (# (u) (eq? (user/name u) "duangsuse"))
  (map user-followers
    (user-followers "duangsuse")))

类似 Kotlin 的伪代码
User("duangsuse").followers.map(User::followers).flatten().filter { it.id == "duangsuse" }

虽然比 SQL JOIN 要优秀，但是明显还是不如图数据库直接 bfs（广度优先搜索可达指定类型目标集合 efficient

不过这次原回答者的回复也不太对，恭喜您发明了Spark。但是这怎么解决写入的问题？

控制权，对上传代码的解释权还是在我们这里啊！我们可以不接受可能不停机的程序、我们可以在程序运行过久的时候强行终止、我们可以只提供有限的基本操作使得没有人可以进行不安全的操作来破坏安全需求，只不过这可能不是特别 efficient 而已

如果你看清了SQL的实质，就会发现这样的“过程式设计”，其实并不会损失SQL的“描述”能力

问题是不看情况打破数据和关系抽象，然后用一个简单粗暴不一定健壮（robuest）的逻辑直接替换掉，是不是有点暴力 🐸 了呢？

总结：

现在但凡是写个需要存储的程序基本上都要某种数据库，而且极大概率是“关系型数据库“。如果真如王垠所说，SQL和关系型数据库如此的不堪，就等价于承认所有SQL/关系型数据库的使用者都是傻X。为什么在关系型数据库从学术到商用长达几十年的历史上没有一个人比王垠更聪明，发现这个问题，并去解决它？虽然理论上的确有这个可能性，但是从直觉上看，这种情况发生的概率又有多少呢？

作者：大宽宽[ref]

我也想引用本频道发过的一段话：

所以有时候，看到『存在即合理』这句话，不要忘记它还有一个深层含义：
如果你一看到某件东西就觉得它很莫名其妙，很弱智，那就不要立刻去喷它，因为*存在即合理*。
如果你依然坚持自己的看法，为什么不思考一下，每天有无数人和你持一样的想法，为什么没有人做出点什么证明它真的没有道理？
是因为它后台很硬，还是看不到它合理性的你们 — 都太菜了？


但是，虽然这里批判了王垠的这篇文章，不代表他的所有文章都该差评，
虽然王垠对某些问题的理解还有点偏差，以及“非工”，擅长理论但工程起来基本菜
但是王垠的技术是很不错的。这一点毋庸置疑。
这篇文章是他 4 年前写的，这几年应该还有长进吧，不知道现在怎么样。

说起来某些工程师吹王垠吹够了没有... CS 方向优秀的大牛不少，只看王垠一个，可惜了。

不要看见乌王垠的部分偏差观点被批评就立刻倒戈批判一番 🐸
至少人家还能同时说出数据结构算法和 PLT 俩领域很多名词，也是很多人一辈子都不能达到的水平了

#这周份的dunangsuse 关键字： Python机器学习 Java 数学 电子
Kotlin KotlinNative 奇怪的问题 WASM CSharp
编译器 逆向工程 字节码 数据结构和算法
QuickHack工程 JavaEE OOP
观点明确
中国 华为
理论：新了解 逻辑式
Haskell Agda 文章评论 王垠

#fix #Cplusplus 这里其实把 C++ 的 Lambda capture 功能弄错了，感谢一位细心读者的反馈！（我去，这么菜的频道还会有读者）

int var = 1;
++var;

auto f = [&]() { cout « var « endl; };


f();

其实这里 & 是 by ref 的 default capture
= 才是 by value 的...（说起来这很 immediate 嘛，两个符号语义明显有区别，这是我一时脑抽了...）

若想详细了解，我写了个例子
编译结果可以在这里查看

#include <iostream>
using namespace std;

int main() {
int var = 1;
auto f = [&]() { cout << var << endl; ++var; };
auto f2 = [=]() mutable { cout << var << endl; ++var; };
//...
}

（同时感谢细心读者的建议）然后在 [&] by ref 的时候有一个要注意的问题，就是从存储对象的『生命周期 lifetime』来看如果 local variable 实际生存期比 Lambda 短，那 lambda 访问时就会出现悬垂指针（dangling pointer）的问题，这一点需要注意

同样我也写了个例子

std::function<void()> higherOrder() {
int upvalue = 0xcafebabe;
return [&]() { printf("Wow! I got upvalue = %i\n", upvalue); };
}

可以在这里阅读 [它的 cppinsight]

其实无视百度公司的其他行为来看，百度学术(xueshu.baidu.com) 还是可以用的

但是他们不重视知识产权，没有对知识最基本的敬畏，到了学术界还是一副对作者的权利的爱理不理的样子... 和以前对那些歌曲一个态度

它太强调免费了... 听起来就像是百度的尿性，养成了那么多死看着免费免费自 high 的网民，改不了啊。

这里有一个例子：

http://xueshu.baidu.com/usercenter/paper/show?paperid=e0f4dfe28ad3be0897827fb00ad16791
http://www.cnki.com.cn/Article/CJFDTotal-SJSJ404.005.htm 知网上也可以免费获取 PDF 拷贝

无关内容：谁知道这个 “CM”(Concurrent Miranda) 是不是蛤为“编译组”的 #huawei

能用咕咕噜用咕咕噜
不能用咕咕噜为什么不问问神奇的必应呢
再加上强行推广狗屎百家号
再加上百度学术也是狗屎除了免费下载屁用没有
再加上至今不肯全站 SSL
而且必应搜中文的结果水平和百度差距不大（甚至更好 包括找题目解析）
垃圾百度（和大数字啊神马啊乱七八糟的）越早扔掉越好

#paper 黄林鹏, 倪德明. 并发函数式语言CM的设计及实现[J]. 计算机工程与设计, 1994(4):38-45.

#recommended #blog https://lfkdsk.github.io/2017/09/11/quick-learn-skip-list/ #data #algorithm

Schoolar 上可以找到和华为所谓 HCC 和 CM、某优化技术什么的相关的内容，但很可惜，都是基本不沾边，只是引用甚至部分内容里稍微提了下华为，而 research 也不是华为弄的

Compiler-inserted predicated tracing
https://patents.google.com/patent/US20110154309A1/en

Compiler with energy consumption profiling
https://patents.google.com/patent/US20090037887A1/en

然后这篇蛤为的论文就是某优化编译算法之前的理论？

Application scenario identification method, power consumption management method, apparatus, and terminal device
应用程序的应用情景识别、功耗管理控制、设备和移动终端
https://patents.google.com/patent/US9813297B2/en

#zhihu #recommended https://www.zhihu.com/question/21350325

https://github.com/duangsuse-valid-projects/Python-ML-intro #Project

#web #gl https://www.taccgl.org/blog/css-transition-visibility.html

这排版测试还是失败了（

所以说，Firefox 才是最好的排版软件嘛（ 真的的让人震惊

这个应该是自然语言处理和机器学习方面的可视化

说起来，弄了半天也没写半个字的实际内容，全搞排版测试什么的去了....

所以说大佬实在不少，哭哭（但其实是好事... 大佬对社会都是“超值”的，就是我们这些菜鸡看了会自闭而已）