在完全不相关的搜索中，我发现了这一点：Lightweight SQL database which doesn't require installation列出了几个可能的选项，目标相同。
我们有一个桌面.Net / WPF应用程序，大型（用于桌面应用程序）存储了大量数据：它具有布局，模板，产品列表和技术规格以及更多内容。
今天它存储在Access数据库中，但是我们很难达到Access限制：它不是很快，数据库权重44Mb（导致大型安装程序包），等等重要的是，使用版本控制很麻烦，因为我们无法将数据从分支合并到另一个分支。例如，我们可能会创建一个分支来添加一些产品，但是当我们合并时，我们必须在主干中手动添加它们。我们可以使用SQL脚本，但为Access编写高级SQL脚本是一件痛苦的事。
基本上，我想用另一种存储格式替换MS Access DB，因为Access没有很好地适应。
我曾尝试使用在安装期间或之后解压缩的JSON文件，但我有点害怕性能问题。
我还考虑将数据拆分为多种格式的多个文件，具体取决于其用途，但使用不同格式可能会使开发变得复杂或烦人。
数据库的某些部分经常被访问并且应该是性能优化的，而其他部分可以在每个工作会话中访问1或2次，并且使用性能较差但高压缩的格式可能没问题。
我们希望安装程序尽可能小，因此库应该很小，格式应该使用小文件。使用向安装程序文件添加5 Mb的库是不可能的。
该软件必须能够在.Net 4（而不是4.5）上运行，如果它在Windows XP上运行会很棒（即使我们正在考虑越来越多的只是放弃它，它＆＆ ＃39;仍占我们市场份额的7％以上。）
此外，它不需要安装服务器（如MS Access或SQLite），因为它将安装在最终用户的计算机上，我们不想让它们膨胀。
应该很容易对数据和数据库结构进行版本控制。该文件应该是文本文件（如JSON），或者脚本应该易于在持续集成平台（如SQL服务器）中运行。
那么，您会使用哪种技术来解决所有这些问题？
谢谢！
答案 0 :(得分：1)
至于你的版本控制难点，从你的描述中可以看出，如果我是你，我将原始数据保存在版本控制的文本文件中，并且只有构建过程从它们生成数据库。这样，您就可以使用SQLite。
答案 1 :(得分：0)
我会选择SQLite，因为文件是独立的，易于定位（因此很容易保存在版本控制系统上），安装程序很小，性能也很好。 http://www.sqlite.org/