正当SQL和no-SQL各自的拥趸们讨论他们各自的优缺点时，我所遇到的一些情况让我不自觉发问：难道就没有第三选择吗？

有些时候，我连关系数据库都不想用。

这种情况是，用户数据就是一些独立文档或表单，而且这些数据并没有和平行的其它数据有逻辑上的关联。而这种情况下，关系数据库似乎不是必须的选择。既然不是一定要用数据库，那么我们是否可以打开思路，想象一些更适合我们业务需求的更好的场景。

我最先想到了Git。

下面举几个例子说明使用Git做为服务器的好处。

GIT的好处

1）Blog

用户写的文章可以在服务端查询到每一次的版本变化，而存数据库要么太冗余，要么会丢掉版本信息。

2）51job

用户的简历的修改在后台都记录。

3）金融贷款申请

用户提交的任何数据都有记录，特别是金融类应用一般都强调WORM(Write Once Read Many)，Git更是天生的完美支持。

4）Git同步

备份都是非常的成熟，方便。

5）Git有成熟的客户端库和通信协议支持

当我开始想demo一下，去Github上找点素材的时候，才发现我的想法一点都不新奇。上面各种Git的客户端，浏览器上运行的库都有，我列出几个给大家参考一下，看看会不会有些灵感。

GIT客户端

JS客户端JS-Git(2790 stargazers)

Java客户端 gitblit(968 stargazers)

Objective-C客户端GitUp (4772 stargazers)

当然，一个服务端应用肯定不止是存储客户端的数据而已，它一定还要包含以下几个方面的功能。

1）鉴别用户，并授权

Bitbucket，Gitlab对这一块的支持都是完美的，也支持单点登录，可以无修改的接入现有业务系统。

2）对客户端提交的数据做出一些判断，并可能触发一些逻辑业务

Bitbucketet和Gitlab就有完整的API接口，可以支持你做几乎所有的功能扩展，包括条件触发，定时任务等。

3）在业务扩大的时候能支持扩展和性能的优化

在我们前面预设的几个场景下，Git的本地repo都将大显身手。

遗憾的是服务端的Git查询似乎永远没有redis，mongoDB查询快，但ParallelGit(https://github.com/beijunyi/ParallelGit) 可以解决你这方面的忧虑。

我可以预见，如果真要开始做这样一种实践，还会遇到各种各样未曾想到的坑。然而值得安慰的是，前面已经有无数人趟了过去，并留下了宝贵的经验，并形成了一股从SQL到no-SQL到no-no-SQL的潮流。

本文编译：刘国平（点融黑帮），资深软件开发工程师，跨平台开发框架hero作者，是最早的一批移动开发者，同时对android，H5，NodeJS等技术比较关注。