键值存储数据库(什么叫键值数据库)
大家好，感谢邀请，今天来为大家分享一下键值存储数据库的问题，以及和什么叫键值数据库的一些困惑，大家要是还不太明白的话，也没有关系，因为接下来将为大家分享，希望可以帮助到大家，解决大家的问题，下面就开始吧！
什么叫键值数据库
首先
文档数据库
和
键值数据库
都是
nosql
第二
文档数据库
最典型的是
mongodb
而
键值数据库
最典型的是
redis
第三
文档数据库
提供嵌入式文档
这对于非规范化非常有用
文档数据库将经常查询的数据存储在同一个文档中
而不是存储在表中
如果一个应用程序需要存储不同的属性
以及大量的数据
那么文档数据库将会是一个很好的选择
第四
键值数据库
适用于那些频繁读写
拥有简单数据模型的应用
键值数据库中存储的值
可以是简单的标量值
如整数或布尔值
也可以是结构化数据类型
比如列表和
json
结构
键值数据库通常具有简单的查询功能
允许通过键来查找一个值
键值存储的四大要素
键值存储的四大基本要素是；数据，计算机，顺序，链式。
键值（key）是windows中注册表中的概念。键值位于注册表结构链末端，和文件系统的文件类似，包含当前计算机及应用程序执行时使用的实际配置信息和数据。键值包含几种数据类型，以适应不同环境的使用需求。注册表中，是通过键和子键来管理各种信息。
如何在嵌入式产品中应用键值存储数据库
flash_set_env("temp","123");
/*修改环境变量temp的值为"456"*/
flash_set_env("temp","456");
/*读取环境变量temp的值*/
char*temp= flash_get_env("temp");
/*删除环境变量temp*/
flash_set_env("temp","");
4、使用场景
目前笔者已应用EasyFlash的产品，主要存储以下内容
1、产品上电的运行参数；
2、运行记录；
3、用户可编辑的参数；
4、软件断言及硬件异常等系统崩溃日志；
5、在线升级时的Bootloader与APP之间的交互参数；
6、更多存储内容有待大家去挖掘??
5、Demo
目前已移植硬件平台有 stm32f10x与 stm32f4xx系列的片内Flash，并支持裸机及RT-Thread嵌入式操作系统。欢迎大家 star and pull request，并提供更多平台的支持及意见。
版权声明：本文为博主原创文章，未经博主允许不得转载。
如何在嵌入式产品中应用键值存储数据库
标签：nosqlstm32数据库key-valueiot
关于数据库存储键值对的问题
这是前端（应用端）和后端（服务端）的问题，这个应该是每个用户的单独配置，那么应该放在前端而是不是放在后端，如果放在后端，那么每个用户都要读取，那么体验一定不好。
对于前端来说，只要加一个“配置文件”（其实就是一段代码）就可以，然后通过服务端的程序读取这个“配置文件”，就知道相应的顺序了，这样总比，连通服务器读取相应的表，来的要快。
如果非要用数据库解决，那我们做一个假设，有100项，某人将所有的项目变成了从后往前倒着写的，也就是第100项与第1项位置互换，第99项与第2项位置互换，这样，那么最后是第50项与第51项调换，也就是100项完全变换了位置，那么不管你怎么存储，怎么读取，这些项都必须全部保存起来，因为每一项的顺序都变了，所以这个方案并不是十分好。
当然，如果非要这么做的话，那么有一个稍微简单一点的办法，不过也需要前端的配合而且，很可能出现征用的情况，使用效果也不一定能太好。
我的办法是建立userid 10001 10002 10003这样一张表，说白了就是一张以默认顺序ModuleID（个人觉得这个可能是你的表头代码，如果不是不要介意）为字段名的表，然后每条用户id，对应一组编号比如（默认编号为1,2,3,4）：
userid 10001 10002 10003 10004
1 4 3 1 2
2 2 1 4 3
3 1 2 3 4
类似于这样就能直接得到用户的编号顺序了，不过这种还是不如在前端一个配置文件来的舒服（用户修改配置文件后，服务端也会备份（类似于上表这种也可以作为一个客户端配置的备份），但是这种备份比直接修改数据库要要省事不少，至少节省了数据库的资源），而且可能出现征用的问题，比如两个人或更多的人同时修改代码，那么一张表不可能让这么多人同时update，肯定要出现征用，那么服务体验就不会太好（备份的话，不用那么及时，所以征用的可能性不大，即使出现也是发生在后端，用户的体验并没有什么影响）。
以上均为个人理解，共同探讨。
文章到此结束，如果本次分享的键值存储数据库和什么叫键值数据库的问题解决了您的问题，那么我们由衷的感到高兴！