在使用云开发进行开发时，数据库权限是一个让不少人困扰的部分，四种数据库权限，到底是什么意思？其各自的权限、应用场景都是什么？大多数人对于这个机制，还是模糊的。为了帮助大家进行更好的开发，在涉及到具体的代码之前，我们先来了解一下云开发的数据库权限机制。
一、为什么会有权限系统？云开发和其他常见的开发模式有一处很大的不同就是，其数据库是可以在小程序端直接进行查询，而无需通过服务端提供的特定 API 接口来完成数据查询。这样就会出现一个问题，这个数据到底谁能查？谁不能查？能查到数据的人，能修改数据么？
在传统的应用开发模式中，权限的控制由服务端的后端接口完成，但是，在云开发的模式中，已经不存在传统的后端，因此，我们需要将权限控制进行向前移，但前端的代码因为无法保证安全（前端的数据可能被篡改，不可信），因此，我们需要将权限控制放在一个更加安全的地方，在经过多方权衡后，最终，云开发数据库就变成了云开发控制台中的一个选项。
二、云开发权限系统中的环境与角色在云开发的权限中，我们会看到一些词，比如创建者、所有人、管理端，这些词应该如何理解呢？
其实这里在命名上是有一些问题的，管理端和创建者、所有人并不是一个好的对比，如果将管理端更名为管理员，会更容易理解。
从权限的层面上来看，从管理端到创建者再到所有人，权限是依次收紧的。
管理端，或者叫管理员，其实便是指云开发中的云函数环境的执行权限。因为是在云函数中执行，安全系数较高，因而获得了最高的权限，也就是所谓的管理端权限。这个权限包括了对于所有的数据进行增、删、改、查的能力。
创建者，则指的是创建某条数据的用户，一般来说，是指在小程序端创建数据的用户。数据和用户之间的绑定是基于数据中的 _openid 来实现的，程序在执行中，当前用户的 openid 与数据的_openid一致时，就认为这个用户是数据的创建者。
所有人，指的是除了管理员以外的用户，这个用户一般而言，也是指小程序端的用户。数据和用户之间并不具备直接的关联关系。用户仅能通过数据库权限配置后的开放读取到用户。
三、关于四个不同的权限云开发的数据库权限共四种，分别是：
1. 仅创建者可写，所有人可读
2. 仅创建者可读写
3. 仅管理端可写，其他人可读
4. 仅管理端可读写
这四种权限各自对应着不同的场景，接下来，我们借一些例子，来看一看四种权限的不同应用场景。
仅创建者可写，所有人可读这种权限是我们使用最多的权限，特别是一些涉及到UGC的场景，我们一定会需要这个权限，因为我们的需求是产生的内容所有人均可读，写的层面则允许数据的创建者可写。
举个例子，如果你做了一个类似朋友圈的应用，那么你一定希望你的用户发的朋友圈可以被其他用户看到，但不能被其他用户修改，不然就乱套了。
仅创建者可读写这种权限一般应用在一些用户的个人隐私信息的场景中。这些信息希望用户自己可以读取，但其他用户无法读取，此时，我们便需要仅创建者可读写。
举个例子，如果你做了个人相册的功能，那么你一定希望这个相册是只有你自己能看，而不是被所有人可以看到，因此，你需要选择仅创建者可读写，而不是仅创建者可写，所有人可读。
仅管理端可写，其他人可读如果描述这个权限的特性，那么就是管理员可以修改，其他人只能看。最适合的场景莫过于各种需要由开发者、平台方管控的东西，比如新闻应用的轮播图列表、商城首页的活动信息等等。这些数据的关键在于所有人都可以看到，同时，所有人也只能看到，不能修改，只能有管理员修改。
举个例子，如果你做了一个电商小程序，那么在你的小程序中，你一定希望首页的推广 Banner 由你自己控制，而不是由用户自行控制，基于这样的考虑，你就需要仅管理端可写，其他人可读的权限。
仅管理端可读写仅管理端可读写，你可以理解为只有云函数中有资格获取这个数据，其他的环境均不允许。这个权限在某些特定的场景下非常有用，举个例子，你的小程序的一些运行日志，你希望在云端可以查看，同时，这个日志不对普通用户展现，这个时候就可以设置为仅管理端可读写。