云开发数据库与传统数据库的不同

在小程序·云开发中，最核心的便是三大组件：数据库、云存储和云函数，从今天开始，我们将开始隔日更的专栏文章，云开发101，在第一周，我们将从最最核心的数据库开始说起。

云开发数据库简介

首先，我们先来了解一下云开发的数据库，云开发数据库是由云开发团队提供给云开发用户的数据库服务，开发者可以在小程序、云函数等环境中，通过简洁易懂的函数调用，来获取到对应的数据，方便开发者快速完成业务逻辑中关于数据库的部分。

在开发过程中，你可以使用诸如 wx.cloud.database().collection('data').where({"age":10}).get() 这样的方法获取到数据库中的信息，而无需再通过服务端提供的 API 完成数据库请求，将数据查询的权力下放到小程序端，加快应用的迭代效率。

云开发数据库底层技术简介

云开发数据库所使用的是 NoSQL （Not Only SQL）数据库方案中的 MongoDB 数据库。MongoDB 数据库是目前业界发展的最好的 NoSQL 数据库，可以让开发者以 SQL 和 NoSQL 两种方式完成数据库结构的建设，快速完成应用的开发。

NoSQL 与 SQL

我们在传统的 Web 应用开发过程中，大多使用的是 SQL 数据库，如 Oracle、SQLite、MySQL、MSSQL 等，但云开发所使用的 MongoDB 则是完全不同的数据库方案，因此，在进行数据库结构设计时，也有所不同。错误的思考模型，会使得你在后续的应用开发过程中，给自己带来无尽的麻烦。因此，也就有了我们这篇文章，向你介绍 NoSQL 世界的魅力。

Schemaless 带来的特性

在我们使用 SQL 数据库开发时我们需要先行设计好数据库的结构、数据表的结构等，而 NoSQL 型数据库，因此，让我们在开发的时候，也会有了不同的开发模式。我们无需在进行应用开发时，先行添加表结构，我们只需要根据我们自己的使用情况，随时增加、删除新的字段，完成自己的业务需求，也正是这种自由，使得云开发有了快速开发、快速迭代的特性。

云开发数据库结构设计思路

由于云开发所使用的数据库类型与我们所熟悉的数据库类型不同，因此，在开发的时候，我们也要相应的修改我们的数据库结构，以适配 NoSQL 数据库的各项特性，从而降低编程时的复杂度，又好又快的满足自己的业务需求。

和 SQL 数据库不同， MongoDB 数据库由于其存储结构从设计之初便是考虑分布式、多节点存储，其 Best Practice 是「以空间换时间」，因此，在设计应用数据结构时，不要考虑应用的数据存储空间，而是更多思考，如何以更快的速度将数据查询出来。

但是，数据库的设计不能完全追求时间，也要思考编程的复杂程度，平衡时间、空间与编程复杂度，以一个更好的方式完成自己的数据库设计。

举个例子，因为极度追求数据的空间换时间，整个数据系统的多种数据仅设计一个集合，所有的数据都挂在一个集合中，显然是不合理的，这种存储会导致应用后续的迭代造成麻烦。

同样的，极度的不追求空间换时间，也是一种错误的选择，如果你将所有的数据都放在各自的独立集合中，则会造成没有很好的利用 NoSQL 数据库的特性，也会使得你的后续编程变得麻烦。

因此，在使用云开发数据库时，我们需要思考我们的业务发展方向，将可能会用到的场景进行割离，思考应用的数据库结构，从而确保自己的应用在后续开发的时候不出问题。

云开发数据库使用常见问题

在实际的应用中，我们也看到，不少人因为不熟悉 NoSQL 的数据库设计理念，在实际开发过程中，出现了不少的问题，这里我们一一讨论一下。

自建主键属性

在 MongoDB 数据库中，数据存储使用的是 ObjectID，因此，其数据的 ID 并非 1 ，2 ，3 ，4 ，而是一个类似于 a718a0f318d76 hash 值，不少人在开发时，因为认为没有自增的数据，无法完成数据排序，就自行实现了一个自增的 ID，每次新增的时候，都重新查询一遍，获取最新的值以后，再重新新增数据。

但实际上，我们可以有一种更加优雅和方便的工具来完成这种需求，那就是新增一个字段 created_at，这个字段的值设置为当前时间的时间戳 Timestamp。当你后续需要进行数据按新增的数据进行排序时，可以使用这个字段进行逆序排序，同时，因为这个数据使用的是当前的时间数据，你还可以将其用于数据的「创建于XX年XX月XX日」的功能，完成自己的业务需求。这个数据除了能进行直接的排序，还可以用于后续按日期导出数据，比如筛选出某一个特定时间段的数据。

相比于一个自增的 ID，created_at 更加的简单易用，同时，因为不需要提前获取上一条记录中这个字段的值，可以有效的降低数据的查询次数。

时间存储问题

在我们进行业务逻辑开发时，时间数据的获取是不可或缺的，不少人习惯于使用一个可视化的日期数据，便会将数据库中的日期字段设置为 2019-09-09，以便于在使用时直接输出到数据库中，但实际上在开发过程中，建议大家存储时间戳 Timestamp 来作为具体的时间。

这是因为 2019-09-09 的数据并非一个可以用于排序的字段，在后续开发的过程中，因为你使用的是字符串作为时间，如果你需要将数据进行排序，将会无法排序或出现排序错误的情况；此外，因为你存储的是字符串类型的时间，那么后续如果你的业务需求发生了展示形式的变化，会导致你花费大量的时间去修改所有数据的时间，或者在数据的读取和存储时进行多次格式转换，徒增麻烦。

因此，对于时间存储有需求的，我们一贯建议大家使用时间戳来存储，因为时间戳是一个数字类型的数据，因此可以直接进行大小的比对，同时，因为时间戳的数据是全球统一的，如果你的应用后续有全球化的需求，也可以很好的支持。