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

这个ＤＥＶＩＣＥ是目前ＳＣＡＬＥ上最前列的，恐怕也最早到ＬＩＴＨＯ的极限。

Adobe可是要推Web OS 的

＝狗狗+M$

如果说C，C++，Java之类，描述的是操作的过程，那么SQL只描述操作的目标，而不关心操作的过程。制订操作过程的计划，交给SQL engine去自动生成，号称execution planning。当然，自动生成的executive plan未必是最优解，所以Oracle等等有分析SQL executive plan的工具，还可以人为干涉SQL executive plan。

SQL的拥护者们说SQL是3GL，第三代语言，言下之意，C，C++，Java之类都是二代语言。但是实践证明，3GL使用并不方便，所以就有了Oracle PL/SQL, 让3GL回归到2.5GL，也就是2GL与3GL的杂拌儿。但是，PL/SQL实际使用起来，既不方便，运行效率还特别差劲儿，所以不是一个成功的语言。

至于把SQL当成操作系统，这个观点，似乎比较新锐了。

• 说得对极了

说到点子上了，见我前帖。

SQL是语言，SQL engine是虚拟机。

如同Java是语言，JVM是虚拟机。

我的基本想法，是SQL更接近当年的C语言的地位，但是那个UNIX在哪里？

有事要出门，以后等我想清楚了继续说。

实践似乎证明，SQL这个东东的作用，比python之类script languages，好不了太多。

3GL的努力，似乎也不了了之。

BerkeleyDB和Bigtable，干脆取消SQL。

JDO，Hibernate之类，倒是力挺SQL。如果Object model与Table-oriented Data Model之间没有gap，那么JDO，Hibernate就没了饭碗。

至于DBA喜欢SQL，那多半是因为熟悉。老家具用顺手了，舍不得丢掉，如此而已。

把离散数学里的集合与SQL对应起来就明白了。所以SQL查询的技巧就是想办法把原本过程性的操作转换成集合性的操作。仅此而已。

怪异的原因在于大部分的程序员已经习惯了过程性的操作，也习惯了循环，所以不明白在做集合操作时有更高效率的优化方法罢了。

它可不怕搜不到你，只有你怕被它搜不到。我发现有些网站google有快照，但是我上去它要我登录，否则不让看，估计就是有对google的bot网开一面设置。

“只描述操作的目标，而不关心操作的过程”的，还有URL。一个“地址”输在浏览器的地址栏里，我管你后台是static page还是php甚至是拿汇编产生出来的结果呢。函数调用也一样，我只关心输入什么你就会输出什么，函数本身的实现就不是我关心的事情了。DB+SQL语言无非就是让我们有了一大个可供调用的函数。

连环雷今晚再度炸响。

SQL的好处是使用方便，但是对于复杂的数据处理，其实非但不方便，反而麻烦。

SQL运行效率差，因为中间环节太多。我对于轻巧快捷的东东有偏爱，不喜欢笨笨的玩意儿。

SQL造成了Object Data Model，与Table Data Model的隔阂，加剧了Database存取的成本。

总之，我得承认，我对SQL有偏见。

SQL不是编程语言，它面对的是集合。

如果用到循环了，那么说明还处在对付每个具体元素的阶段。对于每一个新的刁钻的查询需求，都要编一个用到循环的程序，那恐怕程序员都要累死了。

我宁愿机器累死，也不愿程序员累死。

在R中，也几乎不需要使用循环了，因为一个传统的变量名，现在已经是一个集合了。这时候，用到循环的，反而不轻巧了。

我也对sql有莫大的偏见。

尤其是sqlite，让程序员懒到连桌面和嵌入式程序里，做一个cache subsystem都要用sql

数据库设计的时候，有一个原则就是要理清数据库数据和应用程序数据的关系

数据库是用来做存储和关联处理的，而其他的东西，则应该给应用程序来处理，这个是一般设计上原则。但是话虽然是这么说，目前的数据库其实大部分都在往程序设计上靠拢，甚至有情况下，数据库在统计功能上要比应用程序更快。

你说的cache subsystem的情况，如果是高并发同时需要对并发的数据做实时的统计以及定期扫描的话，其实还是数据库要可靠的多，不然，大部分的数据按照应用程序的思路走的话，要占用多少内存哪，就算是自己转化成硬盘存储，除非自己能设计出存储体系，不然，只是按照应用程序开发语言本身的函数包的话---大部分的函数包似乎都是实现对操作系统的IO接口的调用---，性能要比数据库差的很多。比如CACHE下2万个应用的用户数据的情况，在内存里面保存的话，JAVA的程序估计消耗的内存在10M上下（考虑到统计以及应用的效率，这里用的是哈希的数据），而如果放到磁盘做文件缓存的话，在使用LINUX的情况下，如果使用同一文件夹，查询速度会有明显的下降，更不要说存在对该文件夹的添加以及删除操作了。

在这样的情况下，使用数据库的消耗就要少很多了。保证一个40万数据的快速查询以及相应的添加，并保留对时间上的监控，这几点要求MYSQL就能做的很好了，更不要说商业化的ORACLE,DB2,SQL了。

还是一句话，做什么样的事情要用什么样的工具，存在就是合理的。应用程序语言有应用程序语言的天地，数据库查询语言也有数据库查询语言的空间，这两个是有国境的。

虽然有的时候是模糊了一点。哈哈