是否可以将 Git 用作分层文本数据库？
显然，您必须编写一个充当中间人的前端，将用户命令转换为 git 命令。
记录将对应于一个"文件"。在"文件"中，文本必须具有某种常规格式，例如：
[name]: John Doe
[address]: 13 Maple Street
[city]: Plainview
要执行查询，您必须编写一个 grep 前端以使用 git 的搜索功能。
数据库本身就是存储库。
目录结构将是数据库的分层结构。
我看到的棘手部分是您希望记录在内存中，而不是驱动器上的文件（尽管这是可能的）。因此，您必须将 git 配置为处理虚拟文件系统中的文件，该文件系统实际上位于数据库中间件的内存中。
有点疯狂的想法，但它会奏效吗？
潜在优势：
- 所有记录都将使用 SHA-1 进行哈希处理，因此具有高度的完整性
- git 负责解决所有持久性问题
- 编辑等数据库操作可以作为 Git 合并进行管理
- 记录删除等数据库操作可以作为删除 （RM） 进行管理
- 存储对数据库的所有更改，因此您可以恢复任何更改或以前的状态
- 可以使用克隆制作数据库的副本
是的，但它会非常慢，而且不会涉及 git。 git grep和git clone的功能无需git即可使用。
文件系统可以用作某些类型的数据库。 事实上，git本身将文件系统用作简单、可靠、快速、健壮的键/值存储。 对象4fbb4749a2289a3cd949ebe08255266befd18f23在.git/objects/4f/bb4749a2289a3cd949ebe08255266befd18f23 中。 master分支指向的位置位于 .git/refs/heads/master 中。
文件系统数据库非常不擅长的是搜索这些文件的内容。 如果没有索引，您每次都必须查看每个文件。 您可以使用基本的 Unix 文件实用程序，如 find 和 grep。
此外，您必须解析每次搜索的文件内容，这可能既昂贵又复杂。
并发成为一个严重的问题。如果多个进程想要同时处理一个更改，他们必须复制整个存储库和工作目录，非常昂贵。 然后他们需要进行远程合并，同样昂贵，这可能会导致冲突。 远程访问也有同样的问题。
至于将文件放在内存中，您的操作系统将为您处理这个问题。 它将经常访问的文件保存在内存中。
解决具体问题...
所有记录都将使用 SHA-1 进行哈希处理，因此具有高度的完整性
这只会告诉您文件不同，或者有人篡改了历史记录。 在数据库中，文件应该改变。 它不会告诉您内容是否损坏或格式不正确，或者这是正常更改。
git 负责解决所有持久性问题
不知道这意味着什么。
编辑等数据库操作可以作为 Git 合并进行管理
它们是文件，请编辑它们。我不知道合并是如何参与的。
合并意味着冲突，这意味着人为干预，而不是你想要的数据库。
记录删除等数据库操作可以作为删除 （RM） 进行管理
如果每个文件都是一个记录，是的，但是你可以在没有 git 的情况下做同样的事情。
存储对数据库的所有更改，因此您可以恢复任何更改或以前的状态
这是一个优势，它为您提供事务，但它也会使写入数据库的速度非常慢。Git 并不意味着每秒提交数百次。
可以使用克隆制作数据库的副本
cp -r做同样的事情。
简而言之，除非您正在执行非常简单的键/值存储，否则使用文件系统作为数据库几乎没有什么优势。 像SQLite或Berkeley DB这样的东西几乎在各个方面都更胜一筹。