json 当数据库有什么问题吗

再少的数据我都是直接 mysql ，习惯了

推一手 chaiSQL

json 问题不大，之前写 node 也用过轻量级数据库 lowdb ，它实际上也是用的 json 的

持久化的可靠性，json 方案相当于内存数据库，没解决持久化可靠性问题。如果进程崩了，数据丢失了。
sqlite 把这部分常见的问题都托管了。

直接本地一个 map 就装好了。

看看 duckdb 呢

go 的话接受 kv 可以用 bolt

json 的优势是可以直接用文本编辑器修改，如果用不到这点，相比 sqlite 实在没理由选 json

多大 payload ？希望快就全搂到内存里呗，比任何 IO 都快。。

好搞笑，1w 数据就是手搓一个数据库也绰绰有余，至于 JSON 什么的，你结构化数据出来组装成 JSON 也毫无问题，反而 json 检索太麻烦，〔全文检索除外〕，反正数据库低于 1000w 条记录随便什么数据库都没有问题，哪个方便用哪个就行

用 sqlite 。
如果你不想持久化，想追求极致的快，sqlite 也有 memory 模式，全程不用落盘。

sqlite 的好处是你的数据访问层可以用标准的 sql 来写，万一以后你的业务体量大了，方便切换到其他数据库。不要折腾 json 了。。。。

一萬條記錄 放 slice 遍歷都用不了多久 不要糾結了

几千 1w 的数据隔这纠结半天，我们一天 1 千万数据写 pg 里，感觉离崩溃不远了

@bronyakaka #33 TVT 别骂了别骂了, 就是数据量太小了才纠结一下要不要数据库, 毕竟只是为了持久存

既然是 go 板块，大概率是想避开 sqlite CGO 依赖吧。

目前无需 CGO 的实现就两个思路，要么 modernc.org/sqlite 这种自动化 c 代码转 go 代码的方案，要么就是 modernc.org/sqlite 这种外挂一个中间层通过 ipc 或者什么方式来使用。因为这俩方案在我看来都不理想，所以要么不用，用就老老实实 CGO ，无非就是写个多平台的构建脚本。

一般来说我不推荐用任何文件作为 naive 数据库，因为你需要实现最起码的并发控制（线程安全）、原子写入与（内存和持久化副本）一致性。当然这个东西没那么难，vibe 一下 100 行可能就够用了。不推荐的原因主要还是维护起来麻烦，因为用着用着就发现，这种方案不是很方便存储结构体，需要注意序列化反序列化的问题，然后增删改查也要重新造轮子。日后换方案也是麻烦事。

我比较常用的方案是 etcd-io/bbolt 这个 kv 数据库，该有的功能都有，有个自带的命令行程序，管理导出都方便，不用担心换技术栈。如果不是很依赖 sql 范式对数据做校验，推荐直接把逻辑交给应用代码，数据库就单纯做存储了。这样还有个好处，就是也用不到 orm ，大多数情况下 orm 的表达能力比代码差远了。用 orm 就很容易对调整数据库 schema 的事情产生抵触，毕竟改一次几乎所有语句都会要跟着改，用 kv 数据库一般就没这顾虑。