最近写多了HiveSQL,今天偶尔改了一个很老的java程序，突然想到SQL到底是不是一种OO的语言？
按照历史来说，SQL应该和OO几乎是出生于同一个年代，我无法得知发明SQL的人是否借鉴了OO，或者想出OO的人是否吸纳了SQL的精髓，但是某一些容易被人忽略的东西还是可以印证这两个东西的相似性！
OO的三个基本特点:封装性/继承性/多态性对于SQL来说几乎全部拥有，特别是对于HiveSQL来说，原本的hadoop壳就是基于java,因此转义过来的类SQL更具有OO的特性。
拿封装性来说，类就等于表，当我们在敲打table.的时候，等后续变量出来的感觉就相当于等待class.后面的变量出来；而hiveSQL提供的UDF更像是方法，遗憾的是作为单一的UDF函数不能针对表级别进行处理，如果有table.UDF的话那对于SQL的封装性来说就更趋完美。当然，table.method也不是没有–如果用streaming来做的话–对于一个table进行一个streaming操作，例如python,也就相当于对一个table进行了一个方法。
继承性粗粗看起来没有，其实SQL也可以很好的进行继承。当我们组织中间层的时候，会构造满足tableA同时也满足tableB的表tableC,这里的tableA和tableB不也就是tableC的超类了吗？
多态性目前我还看不出来，如果真要扯一个关系的话，UDF函数算是多态吗？可惜本身就是JAVA！或者说是hive的作者为了将hiveSQL真的做成OO而弄了这么一个玩意出来？不得而知！
上面的这些看起来有点扯淡，其实是因为在平时用SQL的时候有很多东西因为SQL的语法不灵活导致了数据效率的降低！比如可以一道m/r做完的工作，由于SQL的局限性而必须要在两道m/r中完成的情况比比皆是！我觉得其根本原因是程序员很难通过控制SQL去控制mapreduce。如果有一天，我们将SQL变成了类java的语言，生产力一定会有很大的飞跃！我们所有表的变更都能够通过方法来实现，例如tableA.drop,tableA.create,tableA.join,再在这基础上进行重载，可以细化控制到每一个mapreduce,SQL会不会从此变成一门全新的语言呢？
|
Hive
|
Comments (5)
扫一扫
5412
到【灌水乐园】发言
SQL不是面向对象的。而PLSQL是最古老的面向对象的语言之一，借鉴自ada。问题已解决，结贴。
SQL和PLSQL的区别是？
现在就是写HIVESQL的时候没有mapreduce的感觉，很不给力！你知道那种代码在跑，你却不知道下面在干什么的感受！对了，这也是OO的一种哦！
你知道那种代码在跑，你却不知道下面在干什么的感受！ 这句话触动太大了哈。
早年汇编程序员过渡C时，发现C语言对于机器抽象太过于猛烈。想当年那些寄存器运算、内存寻址、访问磁盘io多多少少还有些冯诺依曼结构的影子，再看如今C语言遍地的数组、指针操作已经完全把计算机体系映射到完整的数学逻辑操作。汇编程序员一边大骂C太过于傻瓜化，让大量不懂计算机体系，不懂CPU结构的”愣头青”也能参与到程序开发，而且竟然开发效率大大提高，一边暗自催泪，担忧计算机程序设计领域的壁垒再次降低，自己又掉身价啦。
天生从Java程序入手的程序员会有这种感觉吗？我想肯定没有吧。以汇编程序员观念来看，Java程序至少隔离了三层封装，一层是Java虚拟机，再一层是OS接口，最后还有层C编译器。Java程序员计较这些吗？没有，完全没有，他们把仅剩的精力都用来关注Java社区浓厚的OO情结、无处不在的设计模式堆砌，并以此为荣。在狂热的汇编程序员看来，这些繁文缛节般的抽象，如同带着套套做爱一般，永远体会不到一眼望穿底层的快感。但是快感重要么？工程不是科学，工程不会关注你使用多么底层的语言，不会关注你使用多么牛逼的技术，它只会关注你的代码是否能产生价值。
一个深入捕捉程序热点，反汇编逐字逐节进行优化的代码，其效率是一个普通C程序代码无法比及的吧，这正如一个精心设计m/r作业所处理的TB数据量级，普通的hiveSQL能够轻松应对吗？越能站在本质思考问题的越能够处理更加复杂更加苛刻的极端问题，一个能站在计算机全局思考问题的工程师也是一个优秀的工程师。
但是，一个普通的HiveQL程序员价值几何，一个精熟map/reduce设计的工程师又价值几何？同样是完成大部分的普通ETL日常作业，公司会选谁呢？一个熟悉SQL就能快速上手的Hive，一个需要熟悉Java，熟悉map/reduce的hadoop，公司又会使用什么样的技术? 工业不是科学，利润会一直坚定不移地驱动着工业的发展。