通过一段时间的学习和了解以及前面几篇关于Slick的讨论后对Slick这个函数式数据库编程工具有了些具体的了解。回顾我学习Slick的目的，产生了许多想法，觉着应该从实际的工作应用角度把我对Slick目前能够达到的目的以及在现有功能优势和特点下如何进一步改进才能正真符合IT系统对数据库程序编程和运行效率的要求。想通过这篇博客把想法提出来跟大家分享一下，看看是否能够引起大家的共鸣，为我下一步的工作制定一个方向性的框架。
首先谈谈Slick的特点：主体方面Slick为函数式编程模式带来了SQL编程，可以把数据库表当作scala语言中的集合来对待。除了能实现FP的函数组合外又避免了嵌入SQL语句式的数据库编程，而且也实现了类型安全（type safe），可以由编译器（compiler）在编译时来捕捉语法错误。另一方面与同是基于jdbc之上的通用ORM库比较，Slick可以实现更高效率的关系表数据提取。
Slick实现函数组合部分主要分两个层次：一是Query组合：即把多个Query组成一个Query。我看主要是为了把几个数据源（table）join成一个源头，如下：
1 val q11 = for {
2 c <- coffees.filter(_.price > 100.0)
3 s <- suppliers.filter(_.id === c.supID)
4 } yield (c.id, c.name, s.name)
5 q11.result.statements.head
6 //res4: String = select x2."COF_ID", x2."COF_NAME", x3."SUP_NAME" from "COFFEES" x2, "SUPPLIERS" x3 where (x2."COF_PRICE" > 100.0) and (x3."SUP_ID" = x2."COF_SUP")
7
8 //inner join
9 val q12 = for {
10 c <- coffees.filter(_.price > 100.0)
11 s <- suppliers if s.id === c.supID
12 } yield (c.id, c.name, s.name)
13 q12.result.statements.head
14 //res12: String = select x2."COF_ID", x2."COF_NAME", x3."SUP_NAME" from "COFFEES" x2, "SUPPLIERS" x3 where x2."COF_SUP" = x3."SUP_ID"
15
16 //outter join
17 val q13 = for {
18 c <- coffees.filter(_.price > 100.0)
19 s <- suppliers.filter(_.name === "Acme")
20 } yield (c.id, c.name, s.name)
21 q13.result.statements.head
22 //res6: String = select x2."COF_ID", x2."COF_NAME", x3."SUP_NAME" from "COFFEES" x2, "SUPPLIERS" x3 where (x2."COF_PRICE" > 100.0) and (x3."SUP_NAME" = 'Acme')
上面的例子里示范了把coffees,suppliers两个Query组合成一个joined Query的几种方法，最终结果就是产生一条joined-table的SQL语句。我们也可以用Slick的Query函数组件（combinator）join来达到同样目的，如下：
1 val q14 = for {
2 (c,s) <- coffees join suppliers on (_.supID === _.id)
3 } yield (c.id, c.name, s.name)
4 q14.result.statements.head
5 //res7: String = select x2."COF_ID", x2."COF_NAME", x3."SUP_NAME" from "COFFEES" x2, "SUPPLIERS" x3 where x2."COF_SUP" = x3."SUP_ID"
从函数组合角度来讲：所谓Query组合，功能十分有限。这也符合逻辑：因为最终要形成一条SQL语句。这样说吧：把多条分别读取不同源头的Query组合成一条从合并的源头读取数据的SQL语句也说得通，但其它情况如把一条update Query和insert Query组合成一条SQL就不符合逻辑了。倒是Query的函数组件如filter,take,drop,sortBy,groupBy等在函数式编程中还是比较适用的。
另一个层次的组合是DBIOAction组合，主要目的是编排多个独立Query的运算流程：按照一个组合而成的顺序来运算这些Action。也就是按顺序把每条SQL语句发送到数据库去运算。从函数组合的角度解释又可以理解为按需要把多个独立的数据库操作动作组合成一个完整的数据库操作功能。一项功能里的所有动作可以在一个事务处理（transaction processing）里进行运算。从下面的例子里可以看出端倪：
1 val initSupAction = suppliers.schema.create andThen qInsert3
2 val createCoffeeAction = coffees.schema.create
3 val insertCoffeeAction = qInsert zip qInsert2
4 val initSupAndCoffee = for {
5 _ <- initSupAction
6 _ <- createCoffeeAction
7 (i1,i2) <- insertCoffeeAction
8 } yield (i1,i2)
9
10 //先选出所有ESPRESSO开头的coffee名称，然后逐个删除
11 val delESAction = (for {
12 ns <- coffees.filter(_.name.startsWith("ESPRESSO")).map(_.name).result
13 _ <- DBIO.seq(ns.map(n => coffees.filter(_.name === n).delete): _*)
14 } yield ()).transactionally
15 //delESAction: slick.dbio.DBIOAction[...
16
17 //对一个品种价格升10%
18 def raisePriceAction(i: Long, np: Double, pc: Double) =
19 (for(c <- coffees if (c.id === i)) yield c.price).update(np * pc)
20
21 //对所有价格<100的coffee加价
22 val updatePriceAction = (for {
23 ips <- coffees.filter(_.price < 100.0).map(r => (r.id, r.price)).result
24 _ <- DBIO.seq{ips.map { ip => raisePriceAction(ip._1, ip._2, 110.0)}: _* }
25 } yield()).transactionally
26 //updatePriceAction: slick.dbio.DBIOAction[...
上面例子中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、多源头并行处理：
buildPar(read(age.between(0,10)) //构建并行运算
.with(read(age.between(11,20))
.with(read(age.between(21,50))
.runPar //开始并行读取
.doPar(dataRow,next) //多线程并行处理数据，包括了dataRow移动
上面这些伪代码描述主要是一些运算框架。也就是说我把fs2作为一种数据处理运算的架构。这样的话上面那个doSomeThing就是实现dataRow transformation的地方了，而且必须在类型上、状态转变方式上符合fs2的要求。
可能在下面一段时间里我就会按照自己的理解和想法用scalaz-stream-fs2+Slick来开发一个开源的FunDA（Functional Data Access）函数组件库（combinator library）分享给scala数据库编程的朋友使用。希望无论在开发过程中或者将来的使用中都能得到有共同志愿朋友的参与和帮助。
原创文章，作者：奋斗，如若转载，请注明出处：https://blog.ytso.com/12883.html