一行 sql 也没写过不知道为啥要用这玩意
blob tree grep awk 各种 pipe 倒是一点不怵
我感受不到任何 crud 比 git 更好用的(个人感受
github 就是拿 git 当数据库的, 对吧?(摆事实

老师们我错了我以为我换行了🧎

一行 sql 也没写过不知道为啥要用这玩意

blob tree grep awk 各种 pipe 倒是一点不怵

我感受不到任何 crud 比 git 更好用的(个人感受

github 就是拿 git 当数据库的, 对吧?(摆事实

＃＃补充一点儿:
我个人生产所以内容全都会 git 管理, 索引查询内容都会用正则表达式匹配

＃＃意图:
这个帖子出发点出于“如果我自己不用, 我为什么要用在别人身上?”

数据结构吧

有用 svn 当数据库的

api 不好用

以前有无数据库后端服务 很久很久很久以前

这应该是两个毫无相关的事情的吧，一时不知道怎么吐槽

我对数据库的稳定性不太了解，不过单就 git ，我平均每周一次处理 git break 的事情。。。。

但是为啥会出问题到现在还没明白，都是阿里云的 ecs 实例，看日志也没啥事情。。。。

石头虽然也可以砸钉子，但跟锤子还是有区别的。

我是觉得 sql 降低了一点门槛，让那些不怎么会编程的人，也能用用数据库，写写简单查询语句。

每个人都已经拿 git 当数据库了呀，广义来说一个文本文件都可以是一个数据库，如果你说这不算数据库，那么你就要说说你特指什么数据库了。

对对对，你说的对，你是这条街最靓的仔。

因为你们如果用 git 做数据库，就要再自己做一套数据库底层，而且还不一定做的好

建议了解下 git 底层原理、数据库底层原理。

这是 思而不学则殆。

这里有篇文章 git as nosql databases 文章
www.kenneth-truyers.net/2016/10/13/git-nosql-database/amp/

有道理，万物皆可数据库...

钓鱼还是？

如果不是钓鱼建议转行

git 会存一堆版本的 snapshot ，如果数据更新的频率比较高且数据量大，历史负担会非常重

建议转行

git 本来就是一个 K,V 库

你感觉不到 sql 的好只是你知道的还太少

当我知道原始人用绳结当数据库的时候我已经觉得有问题了，一行 sql 也没写过不知道为啥要用这玩意

你的想法已经有人实现了： github.com/dolthub/dolt

且不说这是两个层面的事情两种大类需求，或者 git 怎么实现 acid 、联表查询、索引树这些底层的玩意儿

单是 git 管理大量的代码或者大容量文件，不分片，你就要抓瞎吐血
不信你试试用 git 去管理一下上十 GB 的项目，或者去管理几个 GB 级的 csv ，或者几百上千个 10MB 级的 csv
这点数据量对任意数据库都是小 case ，对 git 而言就是开发中更新一下都谈不上效率更不可能用于生产

什么？你说给 git 加 feature 加额外的数据结构来实现这些需求？那我为什么不直接用数据库呢？

另外用于数据库版本管理的工具已经有了 -> flywaydb.org

数据量小，业务简单（学生作业级，玩具 demo 级）怎么折腾都可以。想想数据库发明之前，反正就折腾嘛
数据量一大，要上生产，要事务，要并发，要多地热备，各种问题就来了

你说的是 binlog 吧

＃24 undo log

安全无虞 性能捉急啊 商业数据库也要响应速度的啊

看业务,我觉得有些场景下可以

我需要存下商品的价格和联系方式和名称和创建时间吧，然后需要随时查看最新的 10 条商品，，，用 git 怎么实现？？？？

Git 怎么当数据库用？分支作为表，每个 commit 作为 key ，里面的 msg 作为值？我想象力不够……

难道你说的是把一个文本文件作为数据库？

槽点太多，我竟然都不知道该怎么说了。🤯

我记得还有过拿 github 当网盘用的方案呢，后来被站方禁了

一时无法分清是不是反串

不好意思，我看不懂你在说什么。🤕

关系型数据库的关系，你知道是什么吗？

莫名其妙

git 本身只对数据做版本控制，没有任何结构化组织数据、抽象数据的方式吧，因此不能叫做数据库。

当然如果只要能存数据就叫做数据库，那文本也能看作数据库。。

Git for data: github.com/dolthub/dolt

github 也没有提供一个大的 git 仓库用来存取数据吧？只是把每个 git 仓库看作一个实体给用户展示。我猜 github 本身可能有单独的数据库用来存每个 git 仓库

以前还有个帖子的老哥说，RDBMS 和 NoSQL 都是垃圾
自己写项目就用 txt 文档存数据呢
你这 git 有点落后了

+1

“github 就是拿 git 当数据库的, 对吧?(摆事实”

你不会以为 GitHub 的后台就是一个仓库一个文件夹就完事儿了吧。

excel 也算数据库吧

太酷了

我大一的时候就想到这个问题了，ini 也能存数据，要数据库干球

把商品当作 commiter, 它 commit(入库抽象为 commit?)自带名称,时间,联系方式的鸭.

查看最近的十条提交不难吧?

但是你在 github 里面查看 blame 鸭, diff 鸭, commit history 鸭, 这些都是服务器端的 git 操作吧?
这些还能是 github 重写的逻辑? 如果不是的话, 那我用 git 做后台这些功能我就是相当于免费获得的嘛.

我一行 sql 都没写过, 我当然不知道, 不知道才来问啊.

比如 V 站的 1K 个节点、60W 个用户、90W 个帖子、1200W 个回复，

以及每个用户的个人信息、所有提醒通知、虚拟货币消费历史，

还有每个帖子中某些用户的“感谢回复者”记录等，

怎么在 Git 里存储呢？

增删查改 节点、用户及个人信息、帖子、回复、提醒、消费 等，大概咋实现呢？

太年轻呗，没见过世面

我看了下 op 的历史帖子和发言，我只能说。。。。不怕无知，就怕不知道自己无知

不如…… 你写几行 sql 就知道为什么了。
找本数据库教材的入门书，开头的例子就应该感受得到

1. 数据库不等于索引表
2. git 本身也使用了很复杂的数据结构和索引表来管理（甚至是二进制的）数据，与数据库系统有相通点，但完全是两种目的
3. 使用数据库系统的主要目的和关键特性是「关系」这个概念，我们提到数据库系统通常情况下都指的是关系型数据库，它能为现实需求的各种离散数据建立起相互映射，以便能从一套数据查询到另一套数据
4. 在「关系查询」的基础上，现代数据库做了无数无法想象的努力，从数据组织（压缩、值类型、存储优化）到查询算法（索引类型、SQL 、查询计划与优化、地理算法等特殊关系查询）再到网络和并发（事务 /ACID/日志、锁、「连接」: zh.wikipedia.org/zh-cn/%E6%95%B0%E6%8D%AE%E5%BA%93%E8%BF%9E%E6%8E%A5 ） 绝大多数的特性都无法在数据库系统以外的系统中找到

---

教材一般会用这种例子：
建立班级表、学生表、成绩表，查询每班平均成绩，所有班级某成绩以上人数、某学生屡次考试成绩并倒序排列…… 考虑考虑吧

git 本身有用户系统, 复用. 每个节点一个 submodule, 互不干扰, 每个帖子一个 commit obj, 每个‘回复(包括原贴)’ 都是一个 blob obj. 因为不需要文件系统所以不需要 tree obj?

这样可以完全避开系统调用, 所有事情只发生在.git/objects/里

有类似思想的数据库
irmin.org
A distributed database built on the same principles as Git

SQL 还是强在足够表达力的基础上标准化程度高吧

如果不考虑效率和实现难度，什么都可以当数据库。

Git 的主要功能是处理纯文本内容的版本管理（简单说就是增删内容），当然可以用于管理纯文本类型的数据。
当然，我们大可用纯文本把数据保存在一个 Git 仓库里，程序需要的时候就去读一下，还可以上传 Git 服务器备份呢。
（题外话，这种用纯文本文件做数据库的方法叫 DirtyDB ）

这么写的小项目确实跑的很愉快（甚至我有时都这么写），但在面临大规模用户使用（增删查改）的时候，可能会发生一些本来被数据库软件解决了的问题（例如队列、筛选、etc.）。

Git 的命令行输出可以用于查找更改的项目和内容，完全没问题，VSCode 的 Git 集成就是这么做的。

每次 Git 的执行都是独立的进程，问题来了，当我们的服务面临大量用户的时候，运行这些进程会不会造成一些有趣的混乱呢？

总结起来，这个思路可行，就是有点小~糟糕。

git commit-tree 不需要提交到 commit 上, 刚测试过了.

我前天就是跟着这个走了一遍, 但其实 scm 的 git internal 更全面一点.

感谢指点🙇

1. 怎么存储 用户 的 提醒通知（及其是否已读）、历史消费、收藏节点 /主题、关注 /block 的用户？
2. 怎么知道 帖子 有哪些 回复？（回复所属的帖子）
3. 怎么知道 某个回复 有哪些“感谢回复者”记录？
4. 怎么搜索 某个用户 所有帖子、回复？

git 的数据结构一点不复杂哈,immute 三个半, 还有一个 mut 指针, 没啥了, 复杂度不在这吧.

它能为现实需求的各种离散数据建立起相互映射，以便能从一套数据查询到另一套数据

学习了学习了!🙇

这都是后端做的事情吗! 我带着问题学习学习再来回复, 受教了, 感谢提问🙇

虽然 kv nosql 也可以叫数据库, 但正儿八经的数据库 是 关系数据库.
去 leetcode 里, 做完 三道简单的 "数据库" 的题目, 先.

以及，怎么确保『用户消费货币 和 用户发帖 /回复』同时发生或不发生？（防止突然断电、程序突然崩溃等）

这些都是最最最基础的数据库功能，连 1MB 的 SQLite 都能轻易实现

可能数据量太大（而且没有数据），你不好练习

可以去搜索一下『 SQL 经典 50 题』，一些基于『十来行学生、课程、教师、成绩数据』的各种查询，看看怎么用 Git 实现？

Json 也能当数据库的，csv 甚至 txt 也行

你确实可以把 git 当数据库用，如果你了解 git 的底层实现，你就知道它底层其实就是一个 kv 数据库。
但是，如果你真的只是需要一个 kv 数据库而不需要 git 针对版本管理做的业务封装，一般都会有更好的选择。

真有点复杂度的业务不会纯拿 bash 和 coreutils 来写，因为数据处理和错误处理太蛋疼了，换成 python 都会省事些。但在业务不复杂的时候，shell 的低耦合易部署的好处就比较重要了。

你现在觉得 sql 没用，是因为你还没遇到达到那种复杂度的需求。

这句话本身就有问题，就好比问“为什么我们不把牙医当作医生”一样（举个例子）。
因为牙医本身就是医生；而 Git 的核心本身也就是一个数据库。

数据库的范围可能比你想象的要大：即使你想“不用数据库”以文件存储处理数据，然而整个文件系统它也是一个数据库。

同样地，你不能把牙医当全科医生对待，也不能将 Git 当一般数据库用。不是没有可能，而是各有各的擅长之处。

为什么不用 excel 当数据库

以前有文本流的，但是一旦东西多了必须上数据库。
不然数据的问题，会卡死你。

因为你构想出来的用 git 当数据库的场景都很简单。当业务需要复杂的查询和复杂的写入事务，你要给简单操作加上各种一致性约束和保障，加上各种索引，做各种在简单场景下可能是负面操作但复杂场景下反而是优化的设计，最后大概率重新发明关系数据库。

Unix pipe 串起来各种神操作，对于流式数据处理很好用。但在数据量大时，如果需要中途“倒车”，需要各种分组聚合，就麻烦大了。

按 V2 以前常看到劝人找个正经工作上班的说法……你先找个正经数据库作业做一遍看看呗。

git 本来就是一个数据库。再往前，svn 也是一个数据库。再往下，文件系统也是一个数据库。但是你跑业务可不只是要一个数据库。你平时用的是 rdbms ，关系型数据库，是表格型的，而且要符合 acid ，而且对数据完整性，并发性，查询速度以及读写性能都有很高的要求，git 这速度已经很慢了。你会主动选一个比 MySQL 慢 100 倍的数据库吗？

我是受够了 拿 Github 当数据库的人了，一大堆人拿日记，小说往里灌内容，导致 github 的中文搜素，全是垃圾

字符的信息熵太低了, 比不了二进制. 用来检索倒是不错.

纸和笔也能记录数据，拿他当数据库也不错，对吧

理论上来说，txt 也可以当数据库的

我们就是用 svn 当数据存储，不过还是有数据库(当做缓存？)，用于加快系统访问速度

gerrit 的 notedb 就是基于 git 的

想象了一下你用牙签喝粥的样子

告诉你答案了。先入门关系型数据库，然后就懂了。
如果你甚至看不出那是回答，你真要考虑转行。

广义上讲，文件系统也算数据库。但是你这个比较法太 low ，一时不知道该怎么喷了

先看看教材，数据库系统概论就行

首先 Git 是版本控制系统，核心原理就是把你每个版本的文件复制到隐藏的一个单独区域里，跟你写论文每次提交给导师的版本都单独复制出一个文件是一样的，而业务上存取数据并不需要这样的版本控制功能，只需要文件系统帮你存取数据即可。所以数据库用途跟 Git 可能完全没关系，也就是说如果你喜欢的话，完全可以在文件系统上读写文件来存取数据。

任何技术选型都要看需求，通常业务数据库追求的是性能、易用性和一致性，实践是检验真理的唯一标准，题主可以自己尝试写个高并发交互服务，而且要确保事务原子性，你会发现现有的业务数据库帮你做好了很多事情，如果你自己读写文件的话这些事情都要你自己处理，包括对内存的高效利用。

当然不排除个别情况下读写文件就可以满足业务数据管理需求，比如 CMS 。

好像目前是可以实现的，，，关系型数据库的表概念对应 git 库概念对吧？单考虑是否能实现好像确实可以呢。老哥 git 玩挺 6 啊。但是哈，数据库还有分组排序的一些比较细化的功能，git 的话能实现，但是很麻烦，目前想到的是手动创建一个 git 库来专门存索引信息

Homebrew：你说的对

你先用上， 然后教教我。

你说的数据库是 dbms ？ 还是我理解错了

计算机民科成分太高。先当作钓鱼贴

legolasng.github.io/2016/10/16/git-as-a-nosql-database/

这个文章看下是否有帮助
哈哈 我有你微信好友啊

Git 当数据库，那不是区块链的链上数据吗。已经有了啊。

也不是不能，就像在有 sql lite 之前，很多应用都是用纯文本来记录数据的
但是吧,你说为什么编程有这么多种语言，每种语言都活的好好的呢？
各有各的侧重点和应用场景，能帮你简化工作量
基于 git 不是不能做数据库，但是不太匹配日常常见的一些场景

为什么那么多种不同的数据库呢？
如果有时间，可以试试了解一下不同数据库的特性和使用场景，然后假设某个场景替换成 git ，相信答案就出来了

我司有项目 直接写二进制文件

看你怎么定义“数据库”这个东西。

一般来说，我们理解的数据库并不只是一个存储数据的东西，需要是能存储和管理结构化数据的东西，这里的存储需要一定的性能，管理需要提供一定的操作方便性（比如 SQL ），这些 GIT 都不能提供。

所以 GIT 算不上是数据库，最多是一个在特定应用下的数据存储后端。

不同场景用不同方案，没有哪个方案是可以万金油一样放到哪里都适用的
关于用 git 做数据库，可以了解一下 NoteDB gerrit-review.googlesource.com/Documentation/note-db.html

github 还真不是用 git 做数据库的 它用的是 mysql( github.blog/2021-09-27-partitioning-githubs-relational-databases-scale/) 哈哈哈

啊哈!
制服我了.

一堆 NoSQL 数据库都想干掉 SQL ，然后又都用回 SQL 了

学而不思则罔，思而不学则殆

看到大家都在吐槽你。我就放心了