SQLite作为应用程序文件格式

2020-06-13 21:54:52

增量和持续更新。当写入SQLite数据库文件时,只有文件中实际更改的部分才会写出到磁盘。这使得写入速度更快,并减少了固态硬盘的损耗。与定制和包装的文件堆格式相比,这是一个巨大的优势,这两种格式通常都需要写入整个文档才能更改单个字节。纯文件堆格式也可以在一定程度上执行增量更新,尽管使用文件堆格式(单个文件)写入的粒度通常比使用SQLite(单个页面)要大。SQLite还支持持续更新,不是在内存中收集更改,然后仅在File/Save操作中将其写入磁盘,而是可以在更改发生时将其写回磁盘。这样可以避免在系统崩溃或电源故障时丢失工作。使用触发器管理的自动撤消/重做堆栈可以保存在磁盘数据库中,这意味着可以跨会话边界执行撤消/重做。易于扩展。随着应用程序的增长,只需将新表添加到模式或将新列添加到现有表中,就可以将新功能添加到SQLite应用程序文件格式中。添加列或表不会改变先前查询的含义,因此只要稍微小心地确保保留遗留列和表的含义,就可以保持向后兼容性。当然,扩展自定义或文件堆格式也是可能的,但这样做通常要困难得多。如果添加了索引,则必须找到并修改更改对应表的所有应用程序代码,以使这些索引保持最新。如果添加了列,则必须定位并修改访问相应表的所有应用程序代码,以将新列考虑在内。性能:在许多情况下,SQLite应用程序文件格式比文件堆格式或自定义格式更快。除了原始读取和写入的速度更快之外,SQLite通常还可以显著缩短启动时间,因为应用程序无需读取整个文档并将其解析到内存中,而是查询只提取初始屏幕所需的信息。随着应用程序的进展,它只需要加载绘制下一个屏幕所需的材料,并且可以丢弃以前屏幕中不再使用的信息。这有助于控制应用程序的内存占用。文件堆格式可以像SQLite一样以增量方式读取,但许多开发人员惊讶地发现,SQLite可以从其数据库中读取和写入较小的BLOB(大小小于100KB),速度比将这些BLOB作为独立于文件系统的文件进行读取或写入的速度更快。(有关详细信息,请参阅比文件系统和内部BLOB快35%,而不是外部BLOB。)操作关系数据库引擎会产生一些相关开销,但不应假设直接文件I/O快于SQLite数据库I/O,事实往往并非如此。在这两种情况下,如果SQLite应用程序中确实出现了性能问题,通常可以通过向模式中添加一条或两条CREATE INDEX语句或运行一次Analyze来解决这些问题,而无需接触一行应用程序代码。但是,如果以自定义或文件堆格式出现性能问题,修复通常需要对应用程序代码进行大量更改,以添加和维护新索引,或者使用不同的算法提取信息。由多个进程并发使用。SQLite自动协调从多个线程和/或进程对同一文件的并发访问。两个或多个应用程序可以同时连接并读取同一文档。写入是序列化的,但是由于写入通常只需要几毫秒,所以应用程序只需轮流写入。SQLite会自动确保文档的低级格式不会损坏。相比之下,使用自定义或文件堆格式实现同样的功能需要应用程序的广泛支持。而支持并发性所需的应用程序逻辑是臭名昭著的bug磁铁。多种编程语言尽管SQLite本身是用ANSI-C编写的,但是几乎所有你能想到的其他编程语言都有接口:C++、C#、Objective-C、Java、Tcl、Perl、Python、Ruby、Erlang、JavaScript等等。因此,程序员可以使用他们最熟悉的、最符合项目需求的任何语言进行开发。SQLite应用程序文件格式在有多个单独程序的情况下是一个很好的选择,这些程序通常使用不同的语言,由不同的开发团队编写。在研究或实验室环境中,通常会出现这种情况,其中一个团队负责数据获取,其他团队负责不同阶段的分析。每个团队都可以使用他们最熟悉的任何硬件、操作系统、编程语言和开发方法。