你好,我是 EarlGrey,喜欢翻译点东西,偶尔写写代码。
后台回复关键词“电子书”,送你一份我收藏的电子书合集。
众所周知,很多小微型应用程序都需要一些数据处理和计算能力,但如果集成一个数据库就显得太沉重了,正因如此,小巧轻量的 SQLite 才会被广泛应用。
不过,SQLite 也有些不方便的地方。SQLite 对外部数据文件及其它数据源的支持力度比较弱又很繁琐;它本身没有存储过程,需要用主程序配合来实现流程,这会导致经常和主程序交换数据(流程走向依赖于数据),效率低且代码麻烦;复杂些的运算用 SQL 也很难写,开发效率较低。
为了兼顾轻量易用、高效强大等功能,GitHub 上一款名为 esProc SPL 的国产开源数据库应运而生。
GitHub:https://github.com/SPLWare/esProc
esProc 是纯 Java 开发,把 jar 包直接引入到 Java 应用程序中就可以使用了,完全无缝集成。
同时,esProc 也提供了标准 JDBC 接口,就像访问数据库一样可以被 Java 主程序调用,只不过 esProc 使用的查询语言称为 SPL,而不是 SQL。
对于复杂些的运算需求,SPL 写起来要比 SQL 简单多了。
比如:找出销售额占到一半的前 n 个客户,并按销售额从大到小排序。SQL 写出来是这样的:
SQL 很难处理恰好要过线的那条记录,只能换个方法变相实现,即计算销售额从小到大的累计值,反过来找出累计值不在后一半的客户。而且 SQL 要把复杂逻辑写在一句中,即使用了 with 子句(充当中间变量)和窗口函数,仍然要嵌套,技巧性太强,也不好调试。
而 SPL 有更丰富的集合运算,也容易实现分步计算,按自然思维去写就行了:
A | B | |
---|---|---|
1 | =sales.sort(amount:-1) | / 销售额逆序排序 |
2 | =A1.cumulate(amount) | / 计算累计序列 |
3 | =A2.m(-1)/2 | / 最后的累计即总额 |
4 | =A2.pselect(~>=A3) | / 超过一半的位置 |
5 | =A1(to(A4)) | / 按位置取值 |
和大多数写成文本的程序语言不同,SPL 的代码是写在格子里的,这个帖子 写在格子里的程序语言 里有更多信息。
SPL 本身就有完善的流程控制语句,像 for 循环,if 分支都不在话下,还支持子程序调用。这相当于提供了存储过程的能力,只用 SPL 就能实现非常复杂的业务逻辑,几乎不再需要主程序来配合了,主程序只是简单调用它就行了,方法也和调用数据库存储过程一样:
不同的是,SPL 脚本是解释执行的,在修改后就会立即生效,不像存储过程一样需要有个编译过程。特别地,这些脚本可以存放在主程序之外,改动时不需要主程序跟随重新编译部署,可以实现业务逻辑的实时热切换。如果是主程序配合数据库的 SQL 才能实现的逻辑就没有这个好处了。
SPL 支持的数据源就太丰富了。各种格式的文本文件,Excel 文件, 关系数据库,NoSQL 数据库,HTTP,Kafka,…,以及 json/xml 格式的数据,反正你听说过和没听说过的数据源都被 esProc 做好了访问接口,只要简单的一两句代码就可以读写。
访问这些外部数据时不需要事先创建表,直接读就行了,非常方便。而且,这些文件和数据源在 SPL 中都是可写的,所以可以用来做数据持久化,这样写出来的数据还可能被其它应用程序访问。
SPL 还提供了特有的二进制格式文件,可以获得更高的读写性能。
和 SQLIte 类似,esProc 非常轻量,核心 jar 包只有 15M,完整部署也就 1G 左右,它可以在安卓上流畅运行。不过,有点遗憾的是,esProc 目前只有 Java 版本,集成进非 Java 应用程序时相对麻烦,也不能在没有成熟 JVM 环境的 iOS 上工作。
因其简单易用的特性,自开源以来,esProc 的 GitHub Star 一直在持续上涨,截止目前,已在 GitHub 上累计增长 3600+ Star,成为广受开发者喜爱的又一国产数据库。
GitHub:https://github.com/SPLWare/esProc
本文来源:GithubDaily
***
- EOF -