《外文翻译SQLite与众不同的特性.docx》由会员分享，可在线阅读，更多相关《外文翻译SQLite与众不同的特性.docx（13页珍藏版）》请在三一办公上搜索。
1、外文翻译SQLite与众不同的特性附录 附录A：外文资料翻译原文部分 Distinctive Features of SQLite (From SQLite.Org (http:/www.sqlite.org/different.html) This passage highlights some of the characteristics of SQLite that are unusual and which make SQLite different from many other SQL database engines. Zero-Configuration SQLite does
2、 not need to be installed before it is used. There is no setup procedure. There is no server process that needs to be started, stopped, or configured. There is no need for an administrator to create a new database instance or assign access permissions to users. SQLite uses no configuration files. No
3、thing needs to be done to tell the system that SQLite is running. No actions are required to recover after a system crash or power failure. There is nothing to troubleshoot. SQLite just works. Other more familiar database engines run great once you get them going. But doing the initial installation
4、and configuration can be intimidatingly complex. Serverless Most SQL database engines are implemented as a separate server process. Programs that want to access the database communicate with the server using some kind of interprocess communication (typically TCP/IP) to send requests to the server an
5、d to receive back results. SQLite does not work this way. With SQLite, the process that wants to access the database reads and writes directly from the database files on disk. There is no intermediary server process. There are advantages and disadvantages to being serverless. The main advantage is t
6、hat there is no separate server process to install, setup, configure, initialize, manage, and troubleshoot. This is one reason why SQLite is a zero-configuration database engine. Programs that use SQLite require no administrative support for setting up the database engine before they are run. Any pr
7、ogram that is able to access the disk is able to use an SQLite database. On the other hand, a database engine that uses a server can provide better protection from bugs in the client application - stray pointers in a client cannot corrupt memory on the server. And because a server is a single persis
8、tent process, it is able control database access with more precision, allowing for finer grain locking and better concurrency. Most SQL database engines are client/server based. Of those that are serverless, SQLite is the only one that this author knows of that allows multiple applications to access
9、 the same database at the same time. Single Database File An SQLite database is a single ordinary disk file that can be located anywhere in the directory hierarchy. If SQLite can read the disk file then it can read anything in the database. If the disk file and its directory are writable, then SQLit
10、e can change anything in the database. Database files can easily be copied onto a USB memory stick or emailed for sharing. Other SQL database engines tend to store data as a large collection of files. Often these files are in a standard location that only the database engine itself can access. This
11、makes the data more secure, but also makes it harder to access. Some SQL database engines provide the option of writing directly to disk and bypassing the filesystemall together. This provides added performance, but at the cost of considerable setup and maintenance complexity. Stable Cross-Platform
12、Database File The SQLite file format is cross-platform. A database file written on one machine can be copied to and used on a different machine with a different architecture. Big-endian or little-endian, 32-bit or 64-bit does not matter. All machines use the same file format. Furthermore, the develo
13、pers have pledged to keep the file format stable and backwards compatible, so newer versions of SQLite can read and write older database files. Most other SQL database engines require you to dump and restore the database when moving from one platform to another and often when upgrading to a newer ve
14、rsion of the software. Compact When optimized for size, the whole SQLite library with everything enabled is less than 225KiB in size (as measured on an ix86 using the size utility from the GNU compiler suite.) Unneeded features can be disabled at compile-time to further reduce the size of the librar
15、y to under 170KiB if desired. Most other SQL database engines are much larger than this. IBM boasts that its recently released CloudScape database engine is only a 2MiB jar file - 10 times larger than SQLite even after it is compressed! Firebird boasts that its client-side library is only 350KiB. Th
16、ats 50% larger than SQLite and does not even contain the database engine. The Berkeley DB library from Sleepycat is 450KiB and it omits SQL support, providing the programmer with only simple key/value pairs. Manifest typing Most SQL database engines use static typing. A datatype is associated with e
17、ach column in a table and only values of that particular datatype are allowed to be stored in that column. SQLite relaxes this restriction by using manifest typing. In manifest typing, the datatype is a property of the value itself, not of the column in which the value is stored. SQLite thus allows
18、the user to store any value of any datatype into any column regardless of the declared type of that column. (There are some exceptions to this rule: An INTEGER PRIMARY KEY column may only store integers. And SQLite attempts to coerce values into the declared datatype of the column when it can.) As f
19、ar as we can tell, the SQL language specification allows the use of manifest typing. Nevertheless, most other SQL database engines are statically typed and so some people feel that the use of manifest typing is a bug in SQLite. But the authors of SQLite feel very strongly that this is a feature. The
20、 use of manifest typing in SQLite is a deliberate design decision which has proven in practice to make SQLite more reliable and easier to use, especially when used in combination with dynamically typed programming languages such as Tcl and Python. Variable-length records Most other SQL database engi
21、nes allocated a fixed amount of disk space for each row in most tables. They play special tricks for handling BLOBs and CLOBs which can be of wildly varying length. But for most tables, if you declare a column to be a VARCHAR(100) then the database engine will allocate 100 bytes of disk space regard
22、less of how much information you actually store in that column. SQLite, in contrast, use only the amount of disk space actually needed to store the information in a row. If you store a single character in a VARCHAR(100) column, then only a single byte of disk space is consumed. (Actually two bytes -
23、 there is some overhead at the beginning of each column to record its datatype and length.) The use of variable-length records by SQLite has a number of advantages. It results in smaller database files, obviously. It also makes the database run faster, since there is less information to move to and
24、from disk. And, the use of variable-length records makes it possible for SQLite to employ manifest typing instead of static typing. Readable source code The source code to SQLite is designed to be readable and accessible to the average programmer. All procedures and data structures and many automati
25、c variables are carefully commented with useful information about what they do. Boilerplate commenting is omitted. SQL statements compile into virtual machine code Every SQL database engine compiles each SQL statement into some kind of internal data structure which is then used to carry out the work
26、 of the statement. But in most SQL engines that internal data structure is a complex web of interlinked structures and objects. In SQLite, the compiled form of statements is a short program in a machine-language like representation. Users of the database can view this virtual machine language by pre
27、pending the EXPLAIN keyword to a query. The use of a virtual machine in SQLite has been a great benefit to the librarys development. The virtual machine provides a crisp, well-defined junction between the front-end of SQLite (the part that parses SQL statements and generates virtual machine code) an
28、d the back-end (the part that executes the virtual machine code and computes a result.) The virtual machine allows the developers to see clearly and in an easily readable form what SQLite is trying to do with each statement it compiles, which is a tremendous help in debugging. Depending on how it is
29、 compiled, SQLite also has the capability of tracing the execution of the virtual machine - printing each virtual machine instruction and its result as it executes. Public domain The source code for SQLite is in the public domain. No claim of copyright is made on any part of the core source code. (T
30、he documentation and test code is a different matter - some sections of documentation and test logic are governed by open-source licenses.) All contributors to the SQLite core software have signed affidavits specifically disavowing any copyright interest in the code. This means that anybody is able
31、to legally do anything they want with the SQLite source code. There are other SQL database engines with liberal licenses that allow the code to be broadly and freely used. But those other engines are still governed by copyright law. SQLite is different in that copyright law simply does not apply. Th
32、e source code files for other SQL database engines typically begin with a comment describing your license rights to view and copy that file. The SQLite source code contains no license since it is not governed by copyright. Instead of a license, the SQLite source code offers a blessing: May you do go
33、od and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. SQL language extensions SQLite provides a number of enhancements to the SQL language not normally found in other database engines. The EXPLAIN keyword and manifest typing h
34、ave already been mentioned above. SQLite also provides statements such as REPLACE and the ON CONFLICT clause that allow for added control over the resolution of constraint conflicts. SQLite supports ATTACH and DETACH commands that allow multiple independent databases to be used together in the same
35、query. And SQLite defines APIs that allows the user to add new SQL functions and collating sequences. 附录B：外文资料翻译译文部分 SQLite与众不同的特性 ） 这篇文章介绍了SQLite一些不寻常的特性，这些特性使SQLite与其它许多SQL数据库引擎不同。 无需配置 SQLite在使用前不需要“安装”。没有“设置”的程序。没有需要启动、停止或者配置的服务器进程。没有必要让一名管理员去创建一个新的数据库实例或者给用户分配使用权限。SQLite使用无配置的文件。无需做任何事情来告知系统SQL
36、ite正在运行。在系统或者电源故障后不需任何操作来恢复。没有任何问题需要解决。 SQLite就能够这么运行着。 其它许多我们熟悉的数据库引擎一旦你让它们运行起来，它们将运行得非常好。但是前期的安装和配置可能是相当复杂的。 无服务器 大多数SQL数据库引擎被应用为一个分离的服务器处理进程。需要访问数据库的程序必须与服务器进行通讯，它们使用一些进程间通讯的方法将请求发送给服务器并接收发送回的结果。SQLite不采用这种方法工作。对于SQLite而言，需要访问数据库的进程直接读写保存在磁盘上的数据库文件。不存在中间的服务器进程。 无服务器有其优点和缺点。主要优点是它没有分开的服务器进程需要去安装、设
37、置、配置、初始化、管理和排错。这正是SQLite被称为“零配置”数据库引擎的原因之一。使用SQLite的程序，在启动之前，不需要管理员去配置数据库引擎。任何能够读取磁盘的程序都能使用SQLite数据库。 另外一方面，一个使用服务器的数据库引擎在遇到客户端应用程序的Bug时，可以提供更好的保护如客户端遗失的指针无法释放服务器上的内存。并且因为一个服务器是一个单独的持续运行的进程，它能够控制数据库进行高精度的读写，允许完善的原子锁和更好的并发控制。 大多数SQL数据库引擎是基于客户端/服务器模式的。对于那些无服务器的数据库引擎而言，据笔者所知，SQLite是唯一一个允许多个应用程序在同一时间访问同
38、一个数据库的数据库引擎。 单一数据库文件 一个SQLite数据库是一个单独的普通磁盘文件，它可以被放置在目录结构中的任何位置。如果SQLite能够读取该磁盘文件，那么它就可以读取数据库中的任何内容。如果该磁盘文件和它所处的文件夹是可写入的，那么SQLite能够更改数据库中的任何内容。数据库文件能够被非常简单地拷贝到一个USB记忆棒中或者通过电子邮件进行共享。 其它SQL数据库引擎倾向于将数据保存到一个大规模的文件集合中。通常这些文件位于一个标准的地方，只有数据库引擎自己才可以访问。这使得数据更加安全，不过也让它更难访问。一些SQL数据库引擎提供了直接写入磁盘同时绕过文件系统的选项。这提供了附加
39、的性能，不过是以相当大的设置和维护复杂度作为代价的。 稳定的跨平台数据库文件 SQLite文件格式是跨平台的。在一台机器上写的一个数据库文件可以被拷贝到一台不同架构的机器上并使用。大端或小端存储、32位或64位不是问题。所有的机器使用相同的文件格式。此外，开发者保证文件格式的平稳和向下兼容，所以SQLite更新的版本能够读写老版本的数据库文件。 大多数其它的SQL数据库引擎要求你切断并且恢复数据库，当你要将数据库从一个平台转移到另一个平台时，或者当你升级到一个更新版本的软件时。 简洁 当优化文件大小时，一个开启所有功能的完整的SQLite库小于225KB。如果需要的话，不必要的特性可以在编译时
40、禁用，以便于进一步减少库文件的大小使其低于170KB。 大多数其他的SQL数据库引擎比这个大得多。IBM声称，它近期发布的CloudScape数据库引擎“仅仅”为一个2MB的jar文件即使它处于压缩状态，其大小依旧是SQLite的10倍！Firebird声称它的客户端库文件只有350KB大小。那还是比SQLite大了50%，并且还不包括数据库引擎。来自Sleepycat的Berkeley DB库文件是450KB，并且它省略了对SQL的支持，为程序员提供的仅仅是简单的键/值对。 弱类型 大多数SQL数据库引擎使用静态类型。一种数据类型与一张表中的每一列相关联，并且只有属于该特定数据类型的数据被允
41、许存放在该列中。SQLite通过使用弱类型来减少这种限制。在弱类型中，数据类型是数据自己的一个属性，而不是数据所在列的属性。因此SQLite允许用户存储任何数据类型的值到任何列中，而不必考虑该列声明的数据类型。 至于我们可以告诉你的是，SQL语言规范允许使用弱类型。不过，大多数其它的SQL数据库引擎都使用静态类型，所以因此一些人认为SQLite使用弱类型是一个Bug。不过SQLite的作者非常坚持地认为这是一个特性。在SQLite中使用弱类型是一个经过深思熟虑的设计方案，它在实践中已被证实使SQLite更可靠并易于使用，尤其在与使用动态类型的编程语言，如Tcl和Python，结合使用时。 可变
42、长度记录 大多数其它的SQL数据库引擎被分配一个固定数量的磁盘空间来存储大多数表的每一行。它们使用特定的技巧来处理可能无限大的BLOB和CLOB类型数据。不过对于大多数的表，如果你声明一个类型为VARCHAR(100)的列，然后数据库引擎将分配100个字节的磁盘空间，而不考虑你将在该列中实际存储多少信息。 相比之下，SQLite只使用存储一行数据信息所需的实际磁盘空间。如果你在一个VARCHAR(100)类型的列中存储一个单字符，那么它仅消耗一个字节的磁盘空间。 SQLite通过使用可变长度记录有很多优势。很显然，它使数据库文件更小。它也让数据库运行更快，因为它需要从磁盘上读写的数据也更少。并
43、且，对可变长度记录的使用使SQLite用弱类型替换静态类型成为可能。 易读的源代码 SQLite的源代码被设计为易于阅读的，并且一般的程序员也可以理解。所有的程序、数据结构和自动化变量都有详尽的注释，包含有用的信息和开发者做了些什么。引用注释被省略了。 SQL语句编译为虚拟机器码 每个SQL数据库引擎都会将每条SQL语句编译为一些内部的数据结构，然后被用来执行语句所指定的工作。不过在大多数的SQL引擎中，内部数据结构是一张由互联的结构和对象组成的复杂网络。在SQLite中，语句编译的形式为一段短小的类似描述的机器语言程序。数据库的用户可以通过在一个查询前追加EXPLAIN关键字的方式来查看这种
44、虚拟机器语言。 SQLite对虚拟机的使用为程序库的开发带来了极大的便利。虚拟机在SQLite的前台和后台之间提供了一个简单的、定义明确的结合点。虚拟机用易于阅读的形式让开发者看清SQLite对每句编译好的语句尝试做什么，这对调试有极大的帮助。根据它是如何编译的，SQLite同样有能力追踪虚拟机的指令打印每个虚拟机的指令和它运行的结果。 公共领域 SQLite的源代码位于公共领域。任何核心部分的源代码都没有声明版权。所有对于SQLite核心软件的贡献者都已签署宣誓书否定任何代码的版权利益。这意味着任何人用SQLite的源代码能够合法地做他们想做的任何事情。 还有一些签署了自由协议的SQL数据库
45、引擎的源代码允许被自由地传播和使用。不过其它的引擎依旧被著作权法保护。SQLite的不同点在于著作权法根本不适用。 其它SQL数据库引擎的源代码文件典型的一般以一段描述你许可查看和拷贝文件权利的注释开始。SQLite的源代码不包含许可，因为它不被版权管理。取代许可的是，SQLite的源代码提供一个信念： 愿你多做好事少做坏事 愿你自我宽恕也宽恕他人 愿你无私分享，不要获取的比你付出的更多 SQL语言扩展 SQLite提供了一些增强的SQL语言通常不会在其它数据库引擎中出现。EXPLAIN关键字和弱类型上面已经提过了。SQLite还提供了诸如REPLACE和ON CONFICT子句，允许用户控制约束冲突的情况。SQLite支持ATTACH和DETACH命令，它们允许用户将多个相互独立的数据库联合起来完成同一个查询。并且SQLite定义了允许用户添加新SQL功能和排序序列的API函数。
