五千年(敝帚自珍)

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

共:💬233 🌺560
全看树展主题 · 分页首页 上页
/ 16
下页 末页
家园 【原创】浏览器是怎么变成操作系统的 6 云深不知处

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

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

在电子管、晶体管和几十年以前的单片机时代,系统是计算和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更是离数据的语言很远。我们怎样用数据描述这个世界?难道为了任何一种抽象,就要建立一个类。或者做一张表吗?我不认为这样是对的,但是我也不知道什么才是最好的建模方法。或许,这种方法,深深的埋藏在我们的意识里,是我们认识世界的基本方法。或许,这种方法,本身非常的简单。

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

【全文完】

家园 刚把问题抛出来,就草草收尾

select * from data_source where source.property is like

我们应该把SQL作为一个标准来比较,如果标准SQL的查询里面有的东西我们没有,那我们就要认真看看了。

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

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

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

家园 与其给出一个看法,不如提出一个问题

这样才能和大家讨论。

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

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

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

家园 能描述不代表高效阿

regular expression也可以like阿*xxx*

可是这不代表实现高效阿

家园 你说的,不就是MS所提的LINQ的概念嘛

其实就是一种对象化的SQL语言啊,事实上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。我想提醒的是,语言的表达能力越强,实现时所受到的限制越多,还需要仔细权衡。

全看树展主题 · 分页首页 上页
/ 16
下页 末页


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河