kvdb为什么要把字符串类型单独分出来呢？如果去除blob的接口，将所有的数据类型都统一使用fdb_kv_xxx是否API会更简洁易用？

[grape-wzy]

首先感谢朱工创造了FlashDB这么好的开源代码供大家使用。最近在使用过程种产生了如标题所述的疑问，具体描述如下：
fdb_kv_xxx目前是推荐当value为字符串的情况下使用，而其余类型统一使用fdb_kv_xxx_blob，但源码部分与我设想的也是一致，最终字符串类型也是使用blob的结构再往下调用，所以，为什么不直接对外隐藏blob的结构体，将所有相关的API接口都修改成诸如以下形式呢：
fdb_kv_set_blob(fdb_kvdb_t db, const char *key, const void *value, size_t value_size);
fdb_kv_get_blob(fdb_kvdb_t db, const char *key, void *value_buf, size_t buf_len, size_t *value_size);
望朱工解答。

[armink]

那为何要 对外隐藏blob的结构体 呢？现在的 API 有啥问题？

[grape-wzy]

感谢回复。
问题的本意我没有表达清除，让朱工误解了，且上述的举例函数命名也写错了，抱歉。
首先不可否认现在的API在功能上是完全没有问题的，但是使用时候，需要将字符串和其它类型的value作区分，当然，字符串类型也能用blob类型的接口函数，但这样一来，本身留给字符串类型的接口就失去了存在的意义，若能统一起来，只保留以下类型：
fdb_kv_set(fdb_kvdb_t db, const char *key, const void *value, size_t value_size);
fdb_kv_get(fdb_kvdb_t db, const char *key, void *value_buf, size_t buf_len, size_t *value_size);
这样在使用的时候是不是会显得更加统一，代码也更加整洁。并且kvdb内部也不需要@Bool fdb_is_str(uint8_t *value, size_t len) 来判断是否是字符串类型的了，也能提高读取的效率。
最后，统一了API后，其实blob结构体就没有暴露给用户的必要了，可以顺带隐藏在flashdb内部，但saved成员我没有去具体了解功能是否可以用别的方式替代，这一步只是我的构想。
综上，我提出这个discussion的主要目的是：
1、询问将字符串和其它结构类型做统一后，可将flashdb的API简化，也可优化kv函数内部流程，是出于何种考量，当时您设计的时候选择了把字符串类型单独抽出来。
2、如果您觉得可行，是否在之后的版本更新中有这个计划，如果有，我也很愿意为flashdb贡献一份自己的力量。

[armink]

这样改确实看起来更加直观了。

当时增加 blob 的抽象以及 saved 成员的目的，

• 一个是在用户使用迭代器时候，可以再迭代的过程，逐步加载迭代出来的 kv
• 还有一个考虑是对于比较大型的 blob ，系统可能没有比较大的内存空间，一下子把整个 blob 都读取出来，就需要用户通过 read 函数通过流式的方式多次读取

下个版本 v2.1 可以按照你的想法，把 fdb_kv_set 和 fdb_kv_get 取消字符串入参，替换为 void * ，期待新的接口

[grape-wzy]

朱工考虑周全，明白blob的作用了，确实很合理，也很有保留的必要。期待2.1版本更为统一的API。

另外还有个想法，现在KEY的存储是不是直接使用的用户输入的字符串？读取时候检索也是吧？如果把字符串改为对应MD5的校验码，好处我认为有如下几点：

1. 只需要一次MD5的生成就可以在用户读取key时，实现key的快速匹配，值的比对是绝对远远快于字符串比对的。

2. 在大多数的情况下，用户key的长度都是超过4个字节甚至8个字节的，这样，当使用64位的md5时，key的空间占用可能会更小。

3. MD5具有不可逆性，这样也能一定程度上增加用户KEY的保密和数据的安全性。

并且md5的冲撞概率，也已经足够满足用户使用需求了。
我是否需要新建一个Discussion来讨论这个问题？