以前一直是使用关系型数据库,第一次使用Nosql,跟大家分享一下我有限的使用心得,希望对像我一样初使用Nosql的开发者有所帮助。
首先说说微信小程序云开发里集成的这个Nosql,官方并没有说明是哪种Nosql数据库,但从开发文档和暴露的API,还有官方论坛里的讨论来看应该是一个简化版的MongoDB。需要指出的是微信小程序关于云数据库的开发文档非常的简略,对于像我这样没有太多Nosql经验的用户,很多时候需要参考MongoDB的相关文档。
接下来重点谈谈我在使用这个Nosql云数据库时最不适应的一个痛点----文档级别的原子操作。我们经常要使用到原子操作,来避免当多个用户同时对同一个field(字段)编辑时发生冲突。我在使用前其实最担心的痛点是有无schema的区别,但是使用下来发现我挺习惯,也挺喜欢无schema的,后文再详说。现在具体来看看MongoDB只支持document(文档)级别的原子操作。对于我来说,这个限制鼓励我尽量把所有关系都放在一个document里。对此我一开始是有点抗拒的,对于从关系型数据库过来的人特别不习惯。而更让我苦恼的是微信小程序云开发集成的这个云数据库是一个简化版MongoDB,只提供了非常有限的原子操作指令(command)。对于一些常用的document级别原子操作,我必须构想自己的解决办法,而没有提供直接对应的command。以下是两个我在实际开发中遇到的这类问题及我的解决办法:
1.
应用场景:对于一个视频,我需要一个叫total_likes的field(字段),当有用户点击“喜欢”时该field递增1,当有用户取消“喜欢”时该field递减1。
痛点:小程序云数据库只提供了递增指令的原子操作,没有提供递减指令。
const _ = db.command
db.collection('video').doc('video-id').update({
data: {
total_likes: _.inc(1)
}
})
解决办法:要实现递减的原子操作,只需在递增指令里传入负数,如
data: {
total_likes: _.inc(-1)
}
2.
应用场景:对于一个线上课程,我需要一个叫subscribers的field(字段)来记录有多少人订阅了该课程。当有用户点击“订阅”时该字段需记录该用户的id,名字及头像;当有用户取消“订阅”时需把该用户从subscribers字段里删除。
痛点:我们很自然的会想到用数组(Array)数据类型来维护subscribers这个字段,虽然小程序云数据库提供了一些针对数组的原子操作,如push,pop,shift和unshfit,可是无法实现取消订阅这个场景的原子操作。
解决办法:弃用Array转而使用对象(object)数据类型来维护subscribers这个字段。最终的数据看起来会是这样的:
{
"subscribers": {
"userID-1": {
"name": "小明","avatar": "https://avatar-1.com"
},68);">"userID-2": {
"小红",68);">"https://avatar-2.com"
},68);">"userID-3": {
"小李",68);">"https://avatar-3.com"
},...
}
}
const subscriber = "subscribers." + user.id;
db.collection('class').where({
_id: 'classID',}).limit(1).update({
data: {
[subscriber]: {
avatar: user.avatar,name: user.name,}
}
})
).doc('classID').update({
data: {
[subscriber]: _.remove()
}
})
前文说到我很喜欢无schema,因为它非常适合快速迭代开发。而且由于云数据库使用的是类似JSON的数据结构,对于全栈开发者,基本上可以实现由前端来定义数据结构。这样的开发流程非常适合小团队,不需要庞大的并行开发,突出沟通效率和对产品需求的随机应变。顺带一提的是微信小程序云开发能力是从基础库2.2.3开始支持的,但如果要支持所有版本的基础库,可以在 app.json / game.json
中增加字段 "cloud": true
本系列第一章:小程序云开发实战系列01--云环境设置
《Meetup丨活动报名组局》是我最近开发的一个活动报名预约工具小程序,这个系列文章主要来自我在开发这款小程序时的一些体会心得。感兴趣的小伙伴可以扫下面的二维码进入我的小程序。