原文地址：http://www.fossil-scm.org/index.html/doc/tip/www/theory1.wiki
有关于Fossil的二个问题（或者评论）被频繁提及，它们可以概述为如下：
- 为什么Fossil基于SQLite，而不基于分布式的NoSQL数据库？
- 为什么Fossil使用C语言编写，而不是现代的高级语言来开发？
上述二个问题都无法直接回答，因为它们都是基于错误的假设。我们需要声明Fosssil并不是基于SQLite的，且Fossil也不是基于分布式NoSQL的，因为Fossil就是一个分布式的NoSQL数据库。Fossil已经使用了现代的高级语言，名字叫SQL。
一、Fossil是一个NoSQL数据库
我们从第一个问题开始：Fossil不是基于分布式NoSQL的，因为Fossil就是一个分布式的NoSQL数据库。Fossil并不是基于SQLite的。在当前版本的Fossil实现中，SQLite用来本地存储分布式数据库的内容以及快速并简单地描述保存预先计算好的关于分布式数据库变化信息的缓存。在这个任务里使用SQLite是一个实现的细节而不是设计的基本原理。将来的某个版本的Fossil可能会放弃SQLite而使用一堆文件或者Key/Value数据库来取代SQLite。（事实上，好像不太可能会发生，因为SQLite在当前的任务里它工作得难以置信的好，这里只是想说明从Fossil里将SQLite在理论上是完全可行的）
Fossil底层数据库的实现和SQLite或SQL没有任何关系，甚至是关系数据库理论。底层数据库非常简单：它是一个未排序的“artifact”的集合。一个artifact是一个比特列表 — 通俗习惯地理解为一个“文件”。许多artifact可以简化检入Fossil仓库的源码文件的内容。它们叫"content artifacts"。其它artifact，可以叫做"control artifact"，包含了其它artifact之间关系的特定格式的ASCII文字，这个content artifact就像是项目制定版本构成元素。每一个artifact都使用它的哈希值命名。Artifact可以加入数据库但是无法删除（如果我们忽略触发的异常）。通过计算artifact集合的合并来实现仓库的同步。SQL和关系理论在这里没有承担任何任务。
SQL出现在这里只是因为在实现的细节中使用到了它。当前实现的Fossil中每个工件作为BLOB存储在SQLite数据库中。当前实现中每当一个控制工件到达后都会进行解析并将解析结果存储到各类SQLite表单以帮助快速生成报告如时间线、文件历史、文件列表、分支列表等等。 需要注意的是所有这些额外信息都是从工件派生出来的。这些工件都是规则的，关系表只作为缓存来使用。所有关系表内的数据都可以从工件重新计算出来，事实上这个过程就是当你对一个仓库运行“fossil rebuild”命令时所发生的事情。
所以实际上，Fossil使用了二个分离的数据库。一个是非关系的分布式的（类似NoSQL数据库）工件包数据库以及一个本地的关系数据库。工件包数据库是一个混合的格式的Fossil仓库。Fossil永远都不会修改工件包数据库的格式破坏兼容性，如果这样做了会使得某些东西不再是“Fossil”。本地关系数据库包含了从工件包获取的信息的缓存。本地关系数据库的结构会时常变化以增强Fossil实现，数据内容可以从不变动的工件包重新计算后插入。本地关系数据库就也就是一个如何使用SQLite的实现细节。
另外一个如何看待Fossil仓库的关系表的观点是将其视为工件的索引。如果没有关系表，生成一个类似时间线的报告需要扫描每一个工件-等同与全表扫描。关系表保存了指向了相关的预存工件序列，因而创建一个时间线非常高效。因而和关系数据库中的索引一样，Fossil仓库里的关系表不会增加任何新信息，它们只是为了使得工件里的信息可以更快更简单地查询。
Fossil并不"基于"SQLite。Fossil简单地将SQLite作为一个强大的工具来使得开发变得简单。Fossil并没有使用分布式NoSQL数据库，因为Fossil就是一个NoSQL数据库。这就是第一个问题的答案。
二、SQL是一个高级的脚本语言
第二个集中的问题是Fossil没有使用高级脚本语言。但是这不是事实，Fossil使用SQL(和SQLite的实现一样)作为它的脚本语言。
这个误解很有可能会越来越深，因为人们错误地认为SQL不是编程语言。人们认为SQL是一个“查询语言”并假设其与“编程语言”某些地方不一样。但是事实是它们都两种不同风格的同一语言。我发现如果把SQL看成是编程语言的人可以把SQL使用得更好，每一个SQL的声明就是一个分离的程序。SQL是一个独特的编程语言，人们使用它指定计算什么，而相反的是大多数其它编程语言指定的是如何实现这样的计算。这个不同点意味着SQL是一个意义非凡的高级编程语言，但是它任然还是一个编程语言。
对于确定类型的问题，SQL相比其它语言有巨大的优势，因为它太高级而可以让程序员更多地专注于计算什么、高效计算、如何计算的问题上。换句话说，程序员使用SQL语言时倾向于在更高层次上思考问题；这样可以产生更好的程序。SQL语言也非常紧密高效。在实践时，这往往意味着几行SQL语句往往可以取代成百或者上千行的程序代码， 编程采用同样的减少代码的努力往往会导致有更多的几率产生臭虫（BUG）。Fossil遇到哪些问题中的一个使用SQL可以轻松适应。
Fossil开发过程成很多“难以举起”（的问题）使用了SQL申明。事实是，这些SQL申明与C代码粘合在一起，但是令人意外的是C在这个规则下工作得非常棒。几个早期版本的Fossil原型使用的是一个脚本语言（TCL)。我们经常发现TCL程序往往比C语言要简短，大概是10倍或者更多。但是在Fossil的案例上，使用TCL却会使得代码更长且更难理解。所以在最终设计时，我们从TCL转移到了C语言上，从而使得代码更简单地实现和调试。
没有内建SQLite的优势，设计也许会遵循一个不同的路径。Fossil通过仓库数据库中的关系表生成的大多数报告牵涉到完整的全库查询。这些查询往往只使用了很少的几行SQL代码。但是如果这些查询使用程序实现的key/value或者多文件数据库，那么就有可能采取高级脚本语言的方案如Tcl，Python或者Ruby，可能会比C更好实现。
