HarmonyOS 鸿蒙Next 数据持久化使用问题

关于preferences：Key-Value键值型，不适合存放过多的数据，适用的场景一般为应用保存用户的个性化设置（字体大小，是否开启夜间模式）等。

关于relationalStore：基于SQLite组件，适用于存储包含复杂关系数据的场景，比如一个班级的学生信息，需要包括姓名、学号、各科成绩等，又或者公司的雇员信息，需要包括姓名、工号、职位等，由于数据之间有较强的对应关系，复杂程度比键值型数据更高，此时需要使用关系型数据库来持久化保存数据。

官方详细文档供参考：

通过用户首选项实现数据持久化：https://developer.huawei.com/consumer/cn/doc/harmonyos-guides-V13/data-persistence-by-preferences-V13

关系型数据库既可以存储数据量大的数据，也可以满足复杂的关系场景，并不冲突。您这边数据量大优先考虑relationalStore

用户首选项（Preferences）：通常用于保存应用的配置信息。数据通过文本的形式保存在设备中，其持久化文件保存在应用沙箱内部，应用使用过程中会将文本中的数据全量加载到内存中，所以访问速度快、效率高，但不适合需要存储大量数据的场景。Key键为string类型，要求非空且长度不超过80个字节。Value值长度不超过8192个字节。

键值型数据库（KV-Store）：数据以“键值”对的形式进行组织、索引和存储，其中“键”作为唯一标识符。适合很少数据关系和业务关系的业务数据存储，同时因其在分布式场景中降低了解决数据库版本兼容问题的复杂度，和数据同步过程中冲突解决的复杂度而被广泛使用。设备协同数据库，针对每条记录，Key的长度≤896 Byte，Value的长度<4 MB。单版本数据库，针对每条记录，Key的长度≤1 KB，Value的长度<4 MB。

Preferences中的Key键必须是string类型

kvstore是非内存级的，每次写入及读取都是直接操作的db文件，支持数据加密及分布式，底层和RelationalStore一样是SQLite

Preferences是内存级的，在调用flush前都是保存在内存中的，持久化的文件是xml文件，数据明文存储，不支持加密与分布式；number都是按double存储，保留小数点6位。所以数字存储可能有精度问题，使用过程中需要考虑。