这是我写出access-db方法库所经历的一个过程，在这里记录下吧
想法的诞生
小公司的发展本来就不易，成本方面，是能有多节约就多节约。有时多个人干的事转由一个人干，也是毫不奇怪
。也是在这种情况下，我慢慢的成了全栈开发。
最初为了省钱，外加我们只做小程序，就选择了第三方云服务商作为后台。刚开始还好，后面久了，发现他们提供的接口方法使用起来并没有想像的那么轻松。特别是在复杂查寻的情况下，代码太过复杂，不易读，修改起来也不方便。于是我就开始思考怎么去简化他的查寻。下面这个查寻方法，就是封装的最初版，可以看到，fetchFindByCheck使用起来也并不是那么的简单，并且，它还只能支持最简单的and，or查寻，代码的可读性和灵活性都不高。
fetchFindByCheck({
tableName: app.table.active_sign,
relationship: ['and', 'and'],
way: ['in', 'compare', 'compare'],
params: [
{ key: 'child_id', value: childID },
{ key: 'active_id', operator: '=', value: that.aid },
{ key: 'is_delete', operator: '=', value: false },
],
limit: 30,
page: 1,
order_by: '-created_at',
expand: [],
}).then((res2) => {
let tempJoined = res2.data.objects
console.log('tempJoin', tempJoined)
},(err)=>{})但即使如此，我还是封装了一套最简单的方法。
minapp-fetch 出现
用过云服务的肯定都知道，云服务有很多类别的接口。就比如微信云开发，它会提供小程序端的接口、云函数的接口、甚至web接口。我们选择的云服务商，刚开始用得还好，后面由于业务多样化，我们又面临不得不使用web的情况。而且，云服务商提供的web接口也和小程序上面的调用方式不一样，就导致即使同样的查寻，也要写两套不同的查寻方法。如果你还要用他的云函数、或者其他端的api，那更是让你头大。
怎么办呢？为了减轻开发和维护难度，提高开发效率。我产生了一个大胆的想法：要是能把各个端的接口都统一成一种，那不就很简单了吗。想法是好的，但实现起来就没那么容易了。最初在写web端的接口时，我好几次都想放弃，感觉把这些不同的写法，统一成一种，真的是有点难。因为你不但要尽可能的保证同一种增删改查，在不同端得到的结果是一样的，还要通过算法，保证封装的方法尽可能的简单。
经过一段时间的奋斗，方法终于出来了，这个时候，我给它取了一个名字，叫做 minapp-fetch ，现在也发布在了npm上，但它只支持我们使用过的云服务商的api。它的写法更加简洁，如下：
fetchFind(app.table.question, {
p1: {
way: 'compare',
data: ['status', '>', 0]
},
p2: {
way: 'compare',
data: ['is_admin_answered', '=', false]
},
p3: {
way: 'compare',
data: ['is_admin_read', '=', false]
},
r: 'p1 && (p2 || p3)',
page: commen.page,
limit: commen.limit,
order_by: '-created_at',
expand: ['created_by']
})其中，p参数为每一个小条件，r为小条件的and、or，page为翻页，limit为每页数量，order_by为排序。虽然此时看着是比较清晰了，但它还是有不足的地方。首先，p条件写法，还是有些繁琐；其次，就是r规则里面，不支持括号嵌套；再就是，它支持的方法也不多。
面对上面的种种问题，当然是解决了。经过后面的努力，minapp-fetch才有了现在的写法：
其中，p参数对应的定义是这样的：p*: ['字段', '查寻方法', '查寻内容']，数组第一个参数为表里的字段，第二个参数为查寻方法，第三个参数及后面的，就是查寻的内容。
let rule = 'p3 || p7'
minapp.find(table, {
p1: ['cat_label1', 'in', userChannels=[]],
p2: ['cat_label2', 'stringLength', 23], //查寻字符串长度为23的
p4: ['cat_label2', 'stringLength', 23, 100], //查寻字符串长度在23到100的
p3: ['id', 'notIn', history],
p7: ['status', '=', 20],
p8: ['name', 'matches', /^foo/i],
p15: ['geo_point', 'include', [15, 15]], //坐标点，经纬[longitude, latitude]
p21: ['geo_point', 'withinCircle', [15, 15], r], //r 单位 km
p23: ['geo_point', 'withinRegion', [15, 15], max_r], //max_r, min_r 单位为 m
p28: ['geo_point', 'within', [0, 0], [6, 0], [6, 9], [0, 9], [0, 0]], //坐标点集，首点=尾点，经纬[longitude, latitude]
p63: ['content', 'isNull', true],
p93: ['content', 'isExists', false],
r: isSelect ? rule : '(p1 && (p2 || p3)) && (p57 && p93)',
page: 1, //默认值
limit: 20, //默认值
orderBy: '-created_at', //默认值
expand: [], //默认值
select: [], //默认值
withCount: false, //默认值
})可以看到，上面的find方法，已经相当复杂了，但它给人的感觉，还是很清。你甚至可以随意更换r规则，进行不同情况的查寻。（查寻最终是按r规则来的）
access-db 出现
再后来，由于云服务商的一些不足，外加我们自己也对业务灵活性有更多要求，所以决定自己写后台了。慢慢的，我们逐渐开始放弃云服务商，自己开发。此时问题也来了，数据库的连接各不相同，习惯了minapp-fetch写法的我，再去单独用数据库的连接方法，感觉确实不习惯。并且，不同类型的数据库，方法也不一样，维护和转化，成了一大难题。你肯定也猜到了，没错，就是把数据库的连接，也封装起来！
从node.js最火的非关系型数据库mongodb入手，开始了数据库方法封装的旅程。说实在的，mongodb的基本方法和之前云服务商的webapi很相似，也没费太多的功夫就完成了常用方法的封装。但后面加入第二个数据库mysql时，问题就来了。因为mysql是sql语句进行查寻的，和之前的完全不一样。也就是说，必须要通过算法，将封装的写法，转换成sql语句。你可能会觉得，应该不复杂，就是一个简单的组成字符串而已。当初我也是这么认为的，但当我开始入手研发时，才发现，问题远比这个复杂。对mysql了解的同学应该知道，sql语句可以重命名、可以连表查寻、可以嵌套查询、聚合查寻等，并且为了使查寻正确，往往还要对表和字段进行更名，再引用等等，这些问题就使得转化难度大大提高了。可能有时候，你满足了其中一种查寻，却让另一种查寻出了问题。但为了平时开发得更爽，更高效；我还是硬着头皮去实现它。
经过一段时间的苦熬，她终于开始有个样子了，我又重新发了一个npm包，给了她一个全新的名字：access-db，至此，你甚至可以同时引用多种数据库，进行关联使用：
import {mysql, mongodb, fastdb} from 'access-db'
async function exp() {
let {data} = await mongodb.get('table11', id)
await mysql.find('table2', {
p0: ['num', '=', data.num],
r: 'p0'
})
}因为每一种数据库，都有自己的特点，所以，封装的方法里面，肯定会有个体差异，这也无法避免。
Fastdb 出现
细心的同学可能发现了上面的代码中，引入了一种新的数据库fastdb，是的，它是access-db内置的，本地json数据库。也是我发现有类似的本地数据库后，自己开发的。它的优点就是，完全使用access-db语法进行增删改查，同时，不需要你安装任何额外数据库，直接可以用，很方便。缺点也很明显，存储的形式是json文件，没有数据库密码这些，不安全，数据量大了，查寻效率也不是那么高。
结语
我希望通过记录自己的这些经历，能带给你些启发或共鸣。我不是什么大神，可能你也不是，但只要自己不停下思考的脚步，并勇于去实现它，那你也一定能做出有意义东西出来！
将这个方法库，献给那些需要的朋友：
access-db包
access-db文档