Stream 能在 Java 中取代 SQL 吗

很多程序员尝试用 Stream 取代 SQL,但 Stream 缺乏专业的数据对象,在结构化计算方面远不如 SQL 专业。作为对比,SPL 有完善的结构化数据对象,且提供了不依赖于数据库的结构化数据计算能力,在结构化计算方面更加专业。点击Stream 能在 Java 中取代 SQL 吗了解详情。

StreamJAVA 8开始提供的重要类库,提供了更丰富流畅的Lambda语法,能够较方便地实现很多集合运算。基于这个原因,很多程序员尝试用Stream取代SQL。但实际上,Stream的专业程度还远不如SQL

当集合的成员是简单数据类型时(整数、浮点、字符串、日期),Stream可方便地实现集合计算,比如过滤整数数组:

IntStream iStream=IntStream.of(1,3,5,2,3,6);
  IntStream  r1=iStream.filter(m->m>2);

或排序:

Stream r2=iStream.boxed().sorted();

或汇总:

int r3=iStream.sum();

上面的代码简短易懂,程序员能快速掌握。其它像去重distinct \合并concat \包含contain等运算也可以简单地完成。Stream在集合的计算方面的确比较方便。

但结构化计算的数据对象不是简单数据类型,而是记录Map\ entity\ record)。一旦数据对象变成记录,Stream就不那么方便了。比如对订单表的Client字段逆序排序,对Amount字段顺序排序,代码如下:

// OrdersStream<Order>类型,Order是记录类型,定义如下:

//record Order(int OrderID, String Client, int   SellerId, double Amount, Date OrderDate) {}

Stream<Order>    result=Orders

.sorted((sAmount1,sAmount2)->Double.compare(sAmount1.Amount,sAmount2.Amount))

.sorted((sClient1,sClient2)->CharSequence.compare(sClient2.Client,sClient1.Client));

代码明显比SQL复杂,排序字段还要前后颠倒,有点不习惯。另外,代码中的数据对象record会自动实现equals函数,如果采用entity,还需手工实现该函数才能支持排序计算,代码长度又会增加。

排序虽然麻烦些,但逻辑结构还算类似SQL。还有一些计算,逻辑结构上就和SQL不同,对SQL程序员来说就有点陌生了。比如对订单表的SellerId分组,对Amount求和,代码如下:

Map<Object, DoubleSummaryStatistics>   c=Orders.collect(Collectors.groupingBy(r->r.SellerId,Collectors.summarizingDouble(r->r.Amount)));
          for(Object   sellerid:c.keySet()){
              DoubleSummaryStatistics r =c.get(sellerid);
          System.out.println("group   is"+sellerid+"     sum   is"+r.getSum());
  }

分组汇总不止用到groupingBy,还要用collectCollectorssummarizingDoubleDoubleSummaryStatistics等多个类和函数才能实现。而且,分组汇总的结果不再是Stream<Order>之类的常规记录集合,而是Map类型,要用循环才能获取分组汇总的结果,数据类型不如SQL那样一致。

单字段分组汇总还算简单,多字段分组汇总就更麻烦了。比如按年份和Client分组:

Calendar cal=Calendar.getInstance();
  Map<Object, DoubleSummaryStatistics>   c=Orders.collect(Collectors.groupingBy(
          r->{
              cal.setTime(r.OrderDate);
              return   cal.get(Calendar.YEAR)+"_"+r.SellerId;
              },
                Collectors.summarizingDouble(r->{
                  return r.Amount;
              })
          )
  );
      for(Object sellerid:c.keySet()){
          DoubleSummaryStatistics r   =c.get(sellerid);
          String   year_sellerid[]=((String)sellerid).split("_");
          System.out.println("group   is (year):"+year_sellerid[0]+"\t (sellerid):"+year_sellerid[1]+"\t   sum is"+r.getSum());
      }

Stream要先用分隔符(比如下划线)将多个字段合并成一个,转为单字段的分组汇总,计算后再将字段拆开,如此才能实现多字段的分组汇总。这个结构不仅和SQL不同,和本身的单字段汇总比也是差异甚大,不仅SQL程序员感到陌生,恐怕JAVA程序员也有障碍。

上面都是针对单个数据对象的计算,代码已经很复杂了。如果进行多个数据对象之间的计算,代码就会更复杂。比如对两个结构相同的订单表进行交集运算:

Stream<Order>   result=Stream.concat(Orders1, Orders2)
            .collect(Collectors.collectingAndThen(
                    Collectors.toMap(Order::OrderID,
                            Function.identity(),
                          (l, r) -> l,
                            LinkedHashMap::new),
                  f ->   f.values().stream()));

前面无论排序还是分组汇总,都可以用名字直观的函数进行计算(sorted\groupingBy),但计算交集(包括差集、并集)用的却是concat,而concat应该是合集的意思,这就很不直观了。这是因为Stream不支持数据对象之间的计算,只能硬编码实现。这需要一定的技巧和优化能力,对普通程序员要求过高。

Stream不直接支持关联计算。比如对Orders表和Employee表进行内关联,然后对Employee.Dept进行分组,对Orders.Amount求和:

Map<Integer, Employee> EIds =   Employees.collect(Collectors.toMap(Employee::EId, Function.identity()));
  //创建新的OrderRelation类,里面SellerId是单值,指向对应的那个Employee对象。
  record OrderRelation(int OrderID, String Client, Employee SellerId, double   Amount, Date OrderDate){}
  Stream<OrderRelation> ORS=Orders.map(r -> {
      Employee e=EIds.get(r.SellerId);
      OrderRelation or=new   OrderRelation(r.OrderID,r.Client,e,r.Amount,r.OrderDate);
      return or;
  }).filter(e->e.SellerId!=null);
  Map<String, DoubleSummaryStatistics>   c=ORS.collect(Collectors.groupingBy(r->r.SellerId.Dept,Collectors.summarizingDouble(r->r.Amount)));
  for(String dept:c.keySet()){
      DoubleSummaryStatistics r   =c.get(dept);
      System.out.println("groupdept):"+dept+"     sumAmount):"+r.getSum());
  }

硬编码实现的关联计算不仅冗长,而且逻辑复杂。左关联和外关联的代码同样要硬编码,关键的代码逻辑还不一样,编写起来难度更大,这对专业JAVA程序员来说都是个挑战。

关联在结构化数据计算中很重要,Stream对关联计算支持得不好,它在结构化数据计算方面很不专业,远不如SQL

Stream出现之前,Java实现集合类的运算都非常麻烦。Stream的出现改善了JAVA在结构化计算方面不专业的状况,比如,Stream有基本的集合运算,对lambda语法也支持良好。但Stream缺乏专业的结构化数据对象,仍然要使用基于JAVA的数据类型完成运算,再怎么改善也只是动动皮毛。

事实上,直接在JAVA中实现的计算类库都不够专业,根本问题就在于JAVA缺乏专业的结构化数据对象,缺少来自底层的有力支持。结构化计算的返回值的结构随计算过程而变,大量的中间结果同样是动态结构,这些都难以事先定义,而JAVA是强类型语言,又必须事先定义数据对象的结构(否则只能用map这类操作繁琐的数据对象),这就使JAVA的结构化计算僵化死板, lambda语法的能力严重受限。解释性语言可以简化参数的定义,函数本身就可指定参数表达式应解释成值参数还是函数参数,而JAVA是编译型语言,难以区分不同类型的参数,必须设计复杂难懂的接口才能实现匿名函数(主要指lambda语法),这连SQL程序员都不易掌握。省略数据对象而直接引用字段(比如写成“单价*数量”,可显著简化结构化计算,但JAVA缺乏专业的结构化数据对象,目前还无法支持此类表面简单实则巧妙的语法,这就使JAVA代码冗长且不直观(只能写成x.单价*x. 数量”)。

Stream缺乏专业的数据对象,在结构化计算方面远不如SQL专业,SQL虽然足够专业,但必须依赖数据库,两者都有其短板。有时候我们既需要SQL专业的结构化计算语法,又需要Stream的库外计算能力,这种情况应该怎么办?

SPL可以解决这个矛盾。

SPL提供了不依赖于数据库的结构化数据计算能力,它有完善的结构化数据对象,在结构化计算方面和SQL同样专业。对于前面列出的运算,SPLStream写起来简单多了。

比如双字段排序


A

1

=Orders=file("Orders.txt").import@t()

2

=Orders.sort(-Client,   Amount)

上面的@t表示首行读为字段名,后续可以脱离数据对象,直接用字段名进行计算,其中-Client表示逆序。

SPL代码写在单元中,单元格名可以代替变量名,上面代码也可以写作:


A

1

=file("Orders.txt").import@t()

2

=A1.sort(-Client,   Amount)

不影响阅读的情况下,代码也可以写在一行,这样更加简短:


A

1

=file("Orders.txt").import@t().sort(-Client,   Amount)

再比如单字段分组汇总

=Orders.groups(SellerId; sum(Amount))

SPL的语法结构简单一致,扩展成双字段分组汇总时,程序员无需刻意学习即可自然掌握:

=Orders.groups(year(OrderDate),Client; sum(Amount))

SPL是专业的结构化计算语言,不仅可以简化单个数据对象的计算,也很容易进行多数据对象之间的计算。比如两个订单表的子集进行交集运算

=Orders1 ^ Orders2

上面代码中的^是交集运算符,等价于SPL函数isect,类似的集合运算符还有并集&、差集\,以及专门的合集运算符|

同样的内关联计算SPL代码简单多了:

=join(Orders:o,SellerId ;   Employees:e,EId).groups(e.Dept; sum(o.Amount))

类似SQL,只需稍作改动就可以切换关联类型,而无需改动其他代码,比如join@1表示左关联,join@f表示全关联。

SPL提供了通用的JDBC接口,这些SPL代码很容易像嵌入JAVA中执行(类似SQL),或以脚本文件的形式被JAVA调用(类似存储过程)。

        …

          Class.forName("com.esproc.jdbc.InternalDriver");
          Connection connection   =DriverManager.getConnection("jdbc:esproc:local://");
          Statement statement =   connection.createStatement();

        ResultSet   result = statement.executeQuery("=file(\"Orders.txt\").import@t().sort(-Client,   Amount)");

        //result   = statement.executeQuery("call splFileName(?)");

        ...

更多详情参考官方文档,这里不再详细展开

实际上,SPL的计算能力还远远超过SQL。比如下面这些较复杂的例子,用SQL很麻烦,但用SPL就容易多了。

1Duty.xlsx记录着每日值班情况,一个人通常会持续值班几个工作日,之后再换人,现在要根据duty依次计算出每个人连续的值班情况。处理前后的部分数据如下:

处理前(Duty.xlsx

Date

Name

2018-03-01

Emily

2018-03-02

Emily

2018-03-04

Emily

2018-03-04

Johnson

2018-04-05

Ashley

2018-03-06

Emily

2018-03-07

Emily

处理后

Name

Begin

End

Emily

2018-03-01

2018-03-03

Johnson

2018-03-04

2018-03-04

Ashley

2018-03-05

2018-03-05

Emily

2018-03-06

2018-03-07

SQL不擅长处理有序分组问题,要用窗口函数做嵌套子查询,很困难。而SPL提供了有序分组函数,关键代码只要一句。


A

1

=T("D:/data/Duty.xlsx")

2

=A1.group@o(name)

3

=A2.new(name,~.m(1).date:begin,~.m(-1).date:end)

 

2:库表sales存储客户的销售额数据,主要字段有客户client、销售额amount,请找出销售额累计占到一半的前n个大客户,并按销售额从大到小排序。SPL代码如下:


A

B

1

=demo.query(“select client,amount from sales”).sort(amount:-1)

 取数并逆序排序

2

=A1.cumulate(amount)

计算累计序列

3

=A2.m(-1)/2

最后的累计值即是总和

4

=A2.pselect(~>=A3)

超过一半的位置

5

=A1(to(A4))

按位置取值

如果遇到较复杂的计算,SPL通常比SQL更方便,这里既有结构化数据对象更完善的功劳,也有格子代码擅长分步、易于调试的因素。


以下是广告时间

对润乾产品感兴趣的小伙伴,一定要知道软件还能这样卖哟性价比还不过瘾? 欢迎加入好多乾计划。
这里可以低价购买软件产品,让已经亲民的价格更加便宜!
这里可以销售产品获取佣金,赚满钱包成为土豪不再是梦!
这里还可以推荐分享抢红包,每次都是好几块钱的巨款哟!
来吧,现在就加入,拿起手机扫码,开始乾包之旅



嗯,还不太了解好多乾?
猛戳这里
玩转好多乾