September 5, 2009

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

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

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

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

【全文完】

但是,讨论还在继续

No Comments »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a comment 说两句吧