z SQL 数据库引擎 (据我们所知,除 SQLite 之外的所有 SQL 数据库引擎)都使用严格的静态类型。使用静态类型,值的类型便由它的容器 -- 存储值的特定的列 -- 来决定。 SQLite 使用更通用的动态类型系统。在 SQLit 中,值的数据类型与值本身相关,而不是与它的容器。SQLite 的动态类型系统与其它数据库引擎的常用静态类型系统是向后兼容的,在这个意义上,工作在静态类型数据库上的 SQL 语句应该以同样的方式工作在 SQLite 中。然而,SQLite 中的动态类型允许它做传统的严格类型的数据库所不能做的事。 | |||||||||||||||||||||||||||||||||||||
1.0 Storage Classes and DatatypesEach value stored in an SQLite database (or manipulated by the database engine) has one of the following storage classes:
Note that a storage class is slightly more general than a datatype. The INTEGER storage class, for example, includes 6 different integer datatypes of different lengths. This makes a difference on disk. But as soon as INTEGER values are read off of disk and into memory for processing, they are converted to the most general datatype (8-byte signed integer). And so for the most part, "storage class" is indistinguishable from "datatype" and the two terms can be used interchangeably. Any column in an SQLite version 3 database, except an INTEGER PRIMARY KEY column, may be used to store a value of any storage class. All values in SQL statements, whether they are literals embedded in SQL statement text or parameters bound toprecompiled SQL statements have an implicit storage class. Under circumstances described below, the database engine may convert values between numeric storage classes (INTEGER and REAL) and TEXT during query execution. | 译者信息![]() 1.0 存储类型与数据类型存储在 SQLite 数据库中的每个值(或是由数据库引擎所操作的值)都有一个以下的存储类型:
注意,存储类型比数据类型更笼统。以 INTEGER 存储类型为例,它包括6种不同的长度不等的整数类型,这在磁盘上是不同的。但是只要 INTEGER 值从磁盘读取到内存进行处理,它们就被转换为更为一般的数据类型(8字节有符号整型)。因此在一般情况下,“存储类型” 与 “数据类型” 没什么差别,这两个术语可以互换使用。 SQLite 版本3数据库中的任何列,除了整型主键列,都可用于存储任何存储类型的值。 SQL 语句中的任何值,无论它们是嵌入到 SQL 语句中的字面量还是绑定到预编译 SQL 语句中的参数,都有一个隐含的存储类型。在下述情况下,数据库引擎会在执行查询时在数值存储类型(INTEGER 和 REAL)和 TEXT 之间进行转换。 | ||||||||||||||||||||||||||||||||||||
1.1 Boolean DatatypeSQLite does not have a separate Boolean storage class. Instead, Boolean values are stored as integers 0 (false) and 1 (true). 1.2 Date and Time DatatypeSQLite does not have a storage class set aside for storing dates and/or times. Instead, the built-in Date And Time Functions of SQLite are capable of storing dates and times as TEXT, REAL, or INTEGER values:
Applications can chose to store dates and times in any of these formats and freely convert between formats using the built-in date and time functions. | 译者信息![]() 1.1 布尔类型SQLite 并没有单独的布尔存储类型,而是将布尔值存储为整数 0 (false) 和 1 (true)。 1.2 日期和时间类型SQLite 没有另外的存储类型来存储日期和时间。SQLite 的内置的日期和时间函数能够将日期和时间存为 TEXT、REAL 或 INTEGER 值:
应用可以选择这些格式中的任一种存储日期和时间,并使用内置的日期和时间函数在这些格式间自由转换。 | ||||||||||||||||||||||||||||||||||||
2.0 Type AffinityIn order to maximize compatibility between SQLite and other database engines, SQLite supports the concept of "type affinity" on columns. The type affinity of a column is the recommended type for data stored in that column. The important idea here is that the type is recommended, not required. Any column can still store any type of data. It is just that some columns, given the choice, will prefer to use one storage class over another. The preferred storage class for a column is called its "affinity". Each column in an SQLite 3 database is assigned one of the following type affinities:
A column with TEXT affinity stores all data using storage classes NULL, TEXT or BLOB. If numerical data is inserted into a column with TEXT affinity it is converted into text form before being stored. | 译者信息![]() 2.0 类型亲和性为了最大限度地提高 SQLite 和其它数据库引擎之间的兼容性,SQLite 支持列的“类型亲和性”的概念。列的类型亲和性是指数据存储于该列的推荐类型。这里重要的思想是类型是推荐的,而不是必须的。任何列仍可以存储任何类型的数据。这只是让一些列有选择性地优先使用某种存储类型。一个列的首选存储类型被称为它的“亲和性”。 每个 SQLite 3 数据库中的列都归于以下的类型亲和性中的一种:
一个具有 TEXT 亲和性的列使用存储类型 NULL、 TEXT 或 BLOB 存储所有数据。如果数值数据被插入到一个具有 TEXT 亲和性的列,则数据在存储前被转换为文本形式。 | ||||||||||||||||||||||||||||||||||||
A column with NUMERIC affinity may contain values using all five storage classes. When text data is inserted into a NUMERIC column, the storage class of the text is converted to INTEGER or REAL (in order of preference) if such conversion is lossless and reversible. For conversions between TEXT and REAL storage classes, SQLite considers the conversion to be lossless and reversible if the first 15 significant decimal digits of the number are preserved. If the lossless conversion of TEXT to INTEGER or REAL is not possible then the value is stored using the TEXT storage class. No attempt is made to convert NULL or BLOB values. A string might look like a floating-point literal with a decimal point and/or exponent notation but as long as the value can be expressed as an integer, the NUMERIC affinity will convert it into an integer. Hence, the string '3.0e+5' is stored in a column with NUMERIC affinity as the integer 300000, not as the floating point value 300000.0. | 译者信息![]() 数值亲和性的列可能包含了使用所有五个存储类的值。当插入文本数据到数值列时,该文本的存储类型被转换成整型或实数(按优先级排序)如果这种转换是无损或可逆的的话。对于文本与实数类型之间的转换,如果前15个重要十进制数字被保留的话,SQLite认为这种转换是无损并可逆的。如果文本不能无损地转换成整型或实数,那这个值将以文本类型存储。不要试图转换NULL或BLOB值。 一个字符串可能看上去像带有小数点和/或指数符的浮点文字,但只要这个值可以用一个整型表示,数值亲和性就会把它转换成一个整型。因此,字符串‘3.0e+5’以整型300000,而不是浮点值30000.0的形式存储在一个数值亲和性的列里。 | ||||||||||||||||||||||||||||||||||||
A column that uses INTEGER affinity behaves the same as a column with NUMERIC affinity. The difference between INTEGER and NUMERIC affinity is only evident in a CAST expression. A column with REAL affinity behaves like a column with NUMERIC affinity except that it forces integer values into floating point representation. (As an internal optimization, small floating point values with no fractional component and stored in columns with REAL affinity are written to disk as integers in order to take up less space and are automatically converted back into floating point as the value is read out. This optimization is completely invisible at the SQL level and can only be detected by examining the raw bits of the database file.) A column with affinity NONE does not prefer one storage class over another and no attempt is made to coerce data from one storage class into another. | 译者信息![]() 一个使用整型亲和性的列与具有数值亲和性的列表现一致。只是在CAST表达式里,它们之间的区别体现得明显。 除了强制将整型值转换成浮点表示外,一个具有实数亲和性的列与具有数值亲和性的列表现一致(作为一个内部的优化,为了少占用空间,无小数部分且存储在实数亲和性列上的小浮点值以整型形式写到磁盘,读出时自动转换回浮点值。在SQL级别,这种优化是完全不可见的,并且只能通过检查数据库文件的原始比特检测到)。 一个具有NONE亲和性的列不能从一种存储类型转换成另一种,也不要试图强制对它进行转换。 | ||||||||||||||||||||||||||||||||||||
2.1 Determination Of Column AffinityThe affinity of a column is determined by the declared type of the column, according to the following rules in the order shown:
Note that the order of the rules for determining column affinity is important. A column whose declared type is "CHARINT" will match both rules 1 and 2 but the first rule takes precedence and so the column affinity will be INTEGER. | 译者信息![]() 2.1 列亲和性测定列的亲和性是由它的声明类型决定的,按照以下顺序所示的规则: 1. 如果声明类型包含字符串“INT”,那它被指定为整型亲和性; 2. 如果列的声明类型包含任何“CHAR”、“CLOB”或“TEXT”字符串,那么该列具有文本亲和性。注意:VARCHAR类型包含“CHAR”并且被指定为文本亲和性; 3. 如果列的声明类型包含“BLOB”或者没有指定类型,那这列具有NONE亲和性; 4. 如果列的声明类型包含任何“REAL”、“FLOA”或“DOUB”字符串,则该列具有实数亲和性; 5. 否则,它将具有数值亲和性。 注意:判定列亲和性规则的顺序是很重要的。一个具有“CHARINT”声明类型的列将匹配规则1和2,但是规则1优先所有该列具有整型亲和性。 | ||||||||||||||||||||||||||||||||||||
2.2 Affinity Name ExamplesThe following table shows how many common datatype names from more traditional SQL implementations are converted into affinities by the five rules of the previous section. This table shows only a small subset of the datatype names that SQLite will accept. Note that numeric arguments in parentheses that following the type name (ex: "VARCHAR(255)") are ignored by SQLite - SQLite does not impose any length restrictions (other than the large global SQLITE_MAX_LENGTH limit) on the length of strings, BLOBs or numeric values.
Note that a declared type of "FLOATING POINT" would give INTEGER affinity, not REAL affinity, due to the "INT" at the end of "POINT". And the declared type of "STRING" has an affinity of NUMERIC, not TEXT. | 译者信息![]() 2.2 亲和性名字实例下表显示了有多少从更传统的SQL实现的常用数据类型名,通过上一节介绍的五个规则被转换成各种亲和性类型。这张表只显示了SQLite可接受的一小部分数据类型名。注意:跟在类型名后,括号内数值参数(如:VARCHAR(255))将被SQLite忽略 - SQLite不对字符串、BLOBs或数值的长度强加任何限制(除了大型全局SQLITE_MAX_LENGTH限制)。
| ||||||||||||||||||||||||||||||||||||
2.3 Column Affinity Behavior ExampleThe following SQL demonstrates how SQLite uses column affinity to do type conversions when values are inserted into a table.
| 译者信息![]() 2.3 列亲和性行为实例以下SQL演示当有值插入到一张表时,SQLite如何使用列亲和性实现类型转换的: | ||||||||||||||||||||||||||||||||||||
3.0 Comparison ExpressionsSQLite version 3 has the usual set of SQL comparison operators including "=", "==", "<", "<=", ">", ">=", "!=", "<>", "IN", "NOT IN", "BETWEEN", "IS", and "IS NOT", . 3.1 Sort OrderThe results of a comparison depend on the storage classes of the operands, according to the following rules:
| 译者信息![]() 3.0 比较表达式同标准SQL一样,SQLite 3支持如下的比较操作符:"=", "==", "<", "<=", ">", ">=", "!=", "<>", "IN", "NOT IN", "BETWEEN", "IS", 以及 "IS NOT"。 3.1 排序规则比较的结果与操作数的存储类型有关,同时依据以下的规则:
|
转自:http://www.oschina.net/translate/data-types-in-sqlite-version-3?cmp