|
来自：http://www.cr173.com/html/14674_1.html和http://hi.baidu.com/greenappleking/blog/item/afc6a7e8add70b32b90e2ddf.html
SQLite与其他常见的DBMS的最大的不同是它对数据类型的支持。其他常见的DBMS通常支持强类型的数据，也就是每一列的类型都必须预先指定，但是SQLite采用的是弱类型的字段。
一、存储类型和数据类型：
SQLite将数据值的存储划分为以下几种存储类型：
NULL
: 表示该值为NULL值。
INTEGER
: 无符号整型值。
REAL
: 浮点值。
TEXT
: 文本字符串，存储使用的编码方式为UTF-8、UTF-16BE、UTF-16LE。
BLOB: 存储Blob数据，该类型数据和输入数据完全相同。
要注意，这些类型是值本身的属性而不是列的属性
由于SQLite采用的是动态数据类型，而其他传统的关系型数据库使用的是静态数据类型，即字段可以存储的数据类型是在表声明时即以确定的，因此它们之间在数据存储方面还是存在着很大的差异。在SQLite中，存储类型和数据类型也有一定的差别，如INTEGER存储类型可以包含6种不同长度的Integer数据类型，然而这些INTEGER数据一旦被读入到内存后，SQLite会将其全部视为占用8个字节无符号整型。因此对于SQLite而言，即使在表声明中明确了字段类型，我们仍然可以在该字段中存储其它类型的数据。然而需要特别说明的是，尽管SQLite为我们提供了这种方便，但是一旦考虑到数据库平台的可移植性问题，我们在实际的开发中还是应该尽可能的保证数据类型的存储和声明的一致性。除非你有极为充分的理由，同时又不再考虑数据库平台的移植问题，在此种情况下确实可以使用SQLite提供的此种特征。
1. 布尔数据类型：
SQLite并没有提供专门的布尔存储类型，取而代之的是存储整型1表示true，0表示false。
2. 日期和时间数据类型：
和布尔类型一样，SQLite也同样没有提供专门的日期时间存储类型，而是以TEXT、REAL和INTEGER类型分别不同的格式表示该类型，如：
TEXT: "YYYY-MM-DD HH:MM:SS.SSS"
REAL: 以Julian日期格式存储
INTEGER: 以Unix时间形式保存数据值，即从1970-01-01 00:00:00到当前时间所流经的秒数。
具体的值比如SQL语句部分的带双引号或单引号的文字被定义为文本，如果文字没有带引号并没有小数点或指数则被定义为整数，如果文字没有带引号但有小数点或指数则被定义为实数，如果值是空则被定义为空值。BLOB数据使用X'ABCD'来标识
二、类型亲缘性：
为了最大化SQLite和其它数据库引擎之间的数据类型兼容性，SQLite提出了"类型亲缘性(Type Affinity)"的概念。我们可以这样理解"类型亲缘性 "，在表字段被声明之后，SQLite都会根据该字段声明时的类型为其选择一种亲缘类型，当数据插入时，该字段的数据将会优先采用亲缘类型作为该值的存储方式，除非亲缘类型不匹配或无法转换当前数据到该亲缘类型，这样SQLite才会考虑其它更适合该值的类型存储该值。SQLite目前的版本支持以下五种亲缘类型：
|
亲缘类型
描述
TEXT
数值型数据在被插入之前，需要先被转换为文本格式，之后再插入到目标字段中。
NUMERIC
当文本数据被插入到亲缘性为NUMERIC的字段中时，如果转换操作不会导致数据信息丢失以及完全可逆，那么SQLite就会将该文本数据转换为INTEGER或REAL类型的数据，如果转换失败，SQLite仍会以TEXT方式存储该数据。对于NULL或BLOB类型的新数据，SQLite将不做任何转换，直接以NULL或BLOB的方式存储该数据。需要额外说明的是，对于浮点格式的常量文本，如"30000.0"，如果该值可以转换为INTEGER同时又不会丢失数值信息，那么SQLite就会将其转换为INTEGER的存储方式。
INTEGER
对于亲缘类型为INTEGER的字段，其规则等同于NUMERIC，唯一差别是在执行CAST表达式时
REAL
其规则基本等同于NUMERIC，唯一的差别是不会将"30000.0"这样的文本数据转换为INTEGER存储方式。
NONE
不做任何的转换，直接以该数据所属的数据类型进行存储。
1. 决定字段亲缘性的规则：
字段的亲缘性是根据该字段在声明时被定义的类型来决定的，具体的规则可以参照以下列表。需要注意的是以下列表的顺序，即如果某一字段类型同时符合两种亲缘性，那么排在前面的规则将先产生作用。
1). 如果类型字符串中包含"INT"，那么该字段的亲缘类型是INTEGER。
2). 如果类型字符串中包含"CHAR"、"CLOB"或"TEXT"，那么该字段的亲缘类型是TEXT，如VARCHAR。
3). 如果类型字符串中包含"BLOB"，那么该字段的亲缘类型是NONE。
4). 如果类型字符串中包含"REAL"、"FLOA"或"DOUB"，那么该字段的亲缘类型是REAL。
5). 其余情况下，字段的亲缘类型为NUMERIC。
2. 具体示例：
声明类型
亲缘类型
应用规则
INT
INTEGER
TINYINT
SMALLINT
MEDIUMINT
BIGINT
UNSIGNED BIG INT
INT2
INT8
INTEGER
1
CHARACTER(20)
VARCHAR(255)
VARYING CHARACTER(255)
NCHAR(55)
NATIVE CHARACTER(70)
NVARCHAR(100)
TEXT
CLOB
TEXT
2
BLOB
NONE
3
REAL
DOUBLE
DOUBLE PRECISION
FLOAT
REAL
4
NUMERIC
DECIMAL(10,5)
BOOLEAN
DATE
DATETIME
NUMERIC
5
注：在SQLite中，类型VARCHAR(255)的长度信息255没有任何实际意义，仅仅是为了保证与其它数据库的声明一致性。
三、比较表达式：
在SQLite3中支持的比较表达式有："=","==","<","<=",">",">=","!=","<>","IN","NOT IN","BETWEEN","IS" and "IS NOT"。
数据的比较结果主要依赖于操作数的存储方式，其规则为：
1). 存储方式为NULL的数值小于其它存储类型的值。
2). 存储方式为INTEGER和REAL的数值小于TEXT或BLOB类型的值，如果同为INTEGER或REAL，则基于数值规则进行比较。
3). 存储方式为TEXT的数值小于BLOB类型的值，如果同为TEXT，则基于文本规则(ASCII值)进行比较。
4). 如果是两个BLOB类型的数值进行比较，其结果为C运行时函数memcmp()的结果。
四、操作符：
所有的数学操作符(+,-,*,/,%,<<,>>,&,and |)在执行之前都会先将操作数转换为NUMERIC存储类型，即使在转换过程中可能会造成数据信息的丢失。此外，如果其中一个操作数为NULL，那么它们的结果亦为NULL。在数学操作符中，如果其中一个操作数看上去并不像数值类型，那么它们结果为0或0.0。
如下图，创建一个新表，两列的类型分别是int 和varchar，但是还是可以插入其他类型的数据，并且可以正确读出。
要注意SQLite的这种特性可能会给SQLite的ADO驱动造成一些麻烦，因为.NET 都是强类型的语言，必须把数据库中的字段转换为合适的类型，所以在插入数据的时候，还是应该严格的按照create table中的定义插入数据。
（2）自增列
在SQL Server中，只需要指定identity(1,1)就可以设定自增列，但是在SQLite中不支持这样做。在SQLite中，任何一张表都有一个字段 类型是Integer，且是自增的，这个列是作为B树的索引的，它的名字是ROWID，如下图所示：
test2表虽然只有一列，但是ROWID列还是存在的。在程序中对任何一张表都可以使用 ROWID作为自增列。不过这样可能导致和其他数据库的不兼容，SQLite中如果一个列的声明类型是Integer，并且是主键，那么这个列的名字就成 为ROWID的别名。注意，声明类型必须是Integer，而不能是int或bigint之类。例如：
注意上面例子的最后3条语句，它显示了SQLite默认的自增列算法是在当前表中最大的数再 加1，这样可能导致的结果是ID被重复使用——当最后一条数据被删除的时候。这与SQL Server的Identity列的行为是不一致的，例如：
SQL Server会记住每一次插入的序号，哪怕它已经被删除了。要实现SQL Server 这样的效果，需要使用autoincrement关键字。如下例所示：
不过 autoincrement关键字不被SQL Server支持（我不知道SQL 92标准中是否有此关键字），同样SQL Server的 indentity关键字在SQLite中也无法使用，因为SQLite只要求声明类型必须是integer才可以启用自增列。所以，我想不出什么方法能 使建库的脚本能够不加修改的被两种数据库使用。
(3) 日期函数
Sqlite的日期函数比较有特色，它的使用本质上是调用C的库函数strftime,基本 使用方法如下：
(4) 不被支持的特性
用户自定义函数，存储过程
外键的约束（不过可以通过自定义触发器来替代）
right out join,full out join
grant revoke
（编辑：李大同）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
