主题：【原创】浏览器是怎么变成操作系统的 -- 美人他爹

如果说这个系列的前面那些，都是我在忽悠着大家乱跑的话，那么这一贴，请允许我停下来，面对前方的迷雾，说说我不成熟的想法，说说我的惶惑。如果我语无伦次，请多包含。

我在这个系列里面，一直提到计算机和人的共同发展，是以一个系统+语言的模型作为界面的。系统是我们描述现有计算机的抽象模型，语言是我们描述我们希望系统进行的操作的媒介，同时也是我们扩充系统的方式。

在电子管、晶体管和几十年以前的单片机时代，系统是计算和IO模型，语言是汇编；在小型机和PC时代，系统是OS，语言是Algo家族的直系旁系子孙，如C,Pascal等；那么在现在呢？如果你同意我说的，计算机的发展，已经转移到以数据为中心，那么什么是新的系统？什么是新的语言？

我们过去处理数据，是把它们放到数据库里面，切成整齐的表格，然后用SQL来查询它们。但是数据并不老实，它们说，我们不是表格，我们应该可以扩展，鸟可以扩展为鸡，鸡可以扩展为芦花鸡和白斩鸡。于是出现了面向对象数据库。但是internet的出现，让数据变成了网状结构，而且每个页面都只有有限的共同点，剩下的就是不限长度的文字，还有各种资源链接。

在表格结构被各种奇形怪状的数据撑的支离破碎的时候，SQL的命运似乎也应该很惨才对。但是我前面做的一个项目，让我对SQL的描述能力，有了更新的了解。

那个项目是一个web service。限于工作要求，我不能说明具体的实现。但是我可以说的是，我们的数据源绝对不是数据库里面的表格。这个web service的一大任务，是要定义一个查询界面，用来查询数据源里面的数据。

对于这样一个结构复杂的数据源，我们开始定义新的查询语法，设计接近尾声的时候，我们需要确认这个查询语法是完备的，也就是说，它必须能够描述所有数据源里面的数据。

为了这个完备性我们开了四个小时的会，最后我百无聊赖的趴在桌子上面，在笔记本上乱画，随手写出了：

select * from data_source where source.property is like

说实话我把自己吓了一小跳，因为SQL的语法用在这里很合适，尽管我们操作的不是表格。我于是提出，我们应该把SQL作为一个标准来比较，如果标准SQL的查询里面有的东西我们没有，那我们就要认真看看了。

我们的Architect虽然不太情愿说我们重新发明了SQL，但是毕竟这种说法留出了我们的语法是SQL超集的可能性，于是他也接受了。事实证明，我们的数据虽然不是表格，但是SQL语法可以描述我们的查询的绝大多数。

另外一个让我兴奋的事情，就是抛弃了表格这个东西，大多数SQL语法依然成立。比如鸡有腿，兔子也有腿，但是这根本就是两种不同的腿。如果我们局限于表格，那么鸡和兔子应该是两个不同的schema，鸡兔同笼的题目描述起来就困难了（假如我们的数据组织，不仅仅为了做鸡兔同笼的话）。可是，在SQL里面，我们是用名字的，只要被操作的数据有“腿”这个属性，我们就可以描述。这比面向对象还要好，我们不必为了这道题目，专门给鸡和兔子建立一个公共的陆生动物父类。

更进一步，我们可以在笼子里面扔进去蜈蚣，蛇和CPU，只要他们都有N条叫做腿的东西，我们的描述，依然有效。

不过，internet这种网状结构，就是数据的系统模型吗？SQL更是离数据的语言很远。我们怎样用数据描述这个世界？难道为了任何一种抽象，就要建立一个类。或者做一张表吗？我不认为这样是对的，但是我也不知道什么才是最好的建模方法。或许，这种方法，深深的埋藏在我们的意识里，是我们认识世界的基本方法。或许，这种方法，本身非常的简单。

面对新的机会，遥远的路程，云深不知处。

【全文完】

这个问题提得很好，SQL的语汇很有力地表达了大多数针对数据处理的需求。但是问题是，离开了formatted data，如何产生SQL planning？

有趣的问题刚刚展开，就嘎然而止了，sigh。

这样才能和大家讨论。

说实话我自己想了很久，但是一直没有一个确定的方向，所以才把问题放在这里。我一直觉得表格和OO都带有严重的斧凿痕迹，是被计算机严重限制的。这让我很不喜欢。

另一方面，web页面的数据是人和机器都可以识别的一种糅合，尽管这里面，面向的人和机器的成分还是油水分离的状态：<>里面是机器的领域，外面是人的领域。

搜索引擎是机器进入人的领域，把<>之外的数据也进行了索引和处理。但是任何超出索引和匹配的方法，到现在都还是处在研究阶段。或许，formatted data本身，就是过于斧凿？

regular expression也可以like阿*xxx*

可是这不代表实现高效阿

其实就是一种对象化的SQL语言啊，事实上SQL是一种比我们通常使用的编程语言更高级的语言，既有坚实的数学基础，又有丰富的实践经验。

SQL就是一阶谓词逻辑First-Order Logic（FOL），如果你们的语言是FOL的超集，那么你们的语言只能是高阶逻辑Higher-Order Logic（HOL）。在数理逻辑里，HOL比FOL表达能力更强和更加有效，但是在系统的可靠性和完备性方面的限制会更多。通常的一个观点是，FOL能够有效地处理和表达绝大多数的问题，如果不能用FOL表达，只能用HOL，那么有相当大的可能是你的问题本身就有问题。

我倒是不太关心那个语法的事情，毕竟那个项目已经做完了。

我关心的，是这个SQL的语法，其实并不局限于表格和对象，也就是说，如果底层的数据组织方法抛开现在的表格，或者比表格更灵活一些的对象，SQL的基本语法可以不变。

这其实和你说的类似，FOL的描述能力很强，而SQL又已经有巨大的用户群，如果SQL可以描述未来的数据，那当然是运气不错，但是谨慎起见，还是不把SQL作为未来的语言，留出发展空间比较好。

我关心的，是数据如何组织，建模。如羽羊所说，其实都是CRUD。我想，里面的数据如何组织，是更重要的。我回复邓侃的帖子，说表格和对象都有太重的斧凿痕迹，SQL的语法，没有必要限制在表格结构。表格其实是一种高效的数据组织实现方法，但绝对不是唯一的方法。

我赞同你的说法：“SQL的语法，没有必要限制在表格结构。”实际上，SQL只是一种语言，还有许多形式语言或函数式语言具有同样的表达能力，这些语言的语法并不被表格所限定。所以未来的语言也不一定非要限定为SQL。我想提醒的是，语言的表达能力越强，实现时所受到的限制越多，还需要仔细权衡。