上面例子中delEAction比较典型，具体流程是：第一个Query先过滤出需删除的目标，然后把读出结果输入到下一个步骤。下一个步骤按读取目标逐个组成运算删除动作。整个过程在一个transaction里进行。

这样看来Slick的工作原理大体上是：

   构建Query >>> 组合Query >>> 产生SQL语句 >>> 按流程把SQL语句发给数据库进行运算 >>> 获取结果

完成了上面的叙述后，总觉着好像缺少些什么，是一个资深数据库后台软件程序员的感觉。是了，Slick把jdbc的resultset隐藏起来了。其目的可以理解：这样可以实现语法安全（type safety），才能把SQL编程融入FP编程，即scala集合编程。不过SQL是一种批次处理类型的语言，适合数据读取，而处理数据则有些吃力：因为需要逐条数据进行更新。但是，如果在数据库系统里使用cursor的话，无论编程或者运行效率都会很低，况且有些问题在数据库系统内是无法解决的，如：处理一幅图像，这个必须在前端把图像上载内存后利用前端CPU来运算处理。所以把数据从数据库中载入内存再运算的话能提高处理效率。不过针对一连串数据逐个处理的话，我觉着还是rs.next, rs("price")=10.0这种方式会亲切很多。

另外，如果把所有数据处理操作都以SQL语句发到数据库运算的话就无法利用前端计算资源了。单靠数据库服务器来支持所有运算明显是一种错误的运算结构。现代CPU多核已经是普遍现象，也是发展趋势（连手机都是多核的了）。充分利用前端资源不但能提高单项运算效率，而且通过分担服务器负载，能改善整个网络运算效率。我在想：如果能把数据先载入前端内存的话也许还能通过多线程编程来实现数据处理的并行运算，这也是我学习FP的主要目的。

综合以上分析，如果从一个有多年信息管理系统（MIS）开发经验的程序员需求出发，能在工作中使用FRM是一种崭新的体验。与习惯用的ORM比较，从scala编程表达形式和程序运算方式上都有较大的改善。但以Slick当前所能提供的功能还无法完全满足偏重数据处理（data processing）编程的需要。真希望有心人能在Slick3.1的基础上增加一些特色功能，实现以下目标：

1、增加对resultset row的操作支持：

     a) 增加如row.next、row.addNew、row.update、row.delete这样的功能

     b) 在使用row的字段时还能坚持Slick的type safe优点，像这样：row(r.price)=10.0，避免row("price"), row(1)这样的方式

     c) 用纯代码（pure code）方式来实现row变化（transformation），因为程序需要在多线程环境内运算

2、提供数据处理的并行运算功能：

     a) 同时从多个源头（data tables）读取数据

     b) 对row的tranformation实现并行运算

     c) 并行向数据库发送数据更新SQL语句

我个人也对上面的需求进行了一些调研分析，发现scalaz-stream-fs2是个不错的选择，能实现上面的这些要求。首先fs2是个functional stream library，我们仍然可以在FP模式下编程。我们可以用fs2把resultset截成一串row，然后用streaming来实现这个next功能逐条记录移动。而Stream[ROW]就是一个FP类型，可以保证Stream中间ROW类型值的变形处理（transformation）是纯代码，不会产生副作用。

那么，如果能用fs2来实现上述功能要求的话，我们就可以像下面这样来编程了：

1、用伪代码（sudo code）来表述一个最简单的程序流程：

Stream.run(read(PersonFile))  //读取PersonFile
   .doSomeThing(dataRow)      //处理一条数据，可以是更改，也可以是显示
   .next  (.eof)              //移动一步，重复。或者终结

-Stream.run产生了个数据元，Stream.Source

-read是个数据读取函数，产生的结果类型可能是：Seq[DataRow]

-doSomeThing，是一个datarow transformation函数。就是一个Stream.Pipe

-next, 消耗（consume）当前dataRow

-eof, 消耗(drain)所有dataRow

2、多源头并行读取：

buildPar(read(age.between(0,10))  //构建并行运算
  .with(read(age.between(11,20)) .with(read(age.between(21,50)) .runPar //开始多源头并行读取
  .doSomeThing(dataRow)           //处理一条数据
  .next (.eof)                    //移动一步，重复。或者终结

＊我在想：如果doSomeThing是个图片显示（rendering）函数的话，显示满页带相片的个人资料网页是不是会快点？毕竟是并发的I/O

2、并行处理：

Stream.run(read(PersonFile))      //读取PersonFile
  .doPar(dataRow; next)           //多线程并行处理数据，包括了dataRow移动

如果把doPar的类型制成fs2的Stream[F,Stream[F,DataRow]]类型就可以实现并行运算了。对dataRow的消耗（consume）应该包括在运算内

3、多源头并行处理：