SQLite的存储类型与数据类型介绍
1、SQLite的存储类型
除SQLite之外,大多数SQL数据库引擎都使用严格的静态类型。使用静态类型,列有严格的类型约束,例如MySQL的数据类型有:
整数类型:BIT、BOOL、TINY INT、SMALL INT、MEDIUM INT、 INT、 BIG INT
浮点数类型:FLOAT、DOUBLE、DECIMAL
字符串类型:CHAR、VARCHAR、TINY TEXT、TEXT、MEDIUM TEXT、LONGTEXT、TINY BLOB、BLOB、MEDIUM BLOB、LONG BLOB
日期类型:Date、DateTime、TimeStamp、Time、Year
SQLite使用更通用的动态类型系统,也就是说:任何列仍然可以存储任何类型的数据。针对不同的数据,SQLite数据库提出了若干存储类型,如下表所示:
存储类 | 描述 |
---|---|
NULL | 表示值为空(null )值。 |
INTEGER | 表示值是一个有符号整数,根据值的大小存储在1 ,2 ,3 ,4 ,6 或8 个字节中。 |
REAL | 表示值是一个浮点值,存储为8 位IEEE浮点数。 |
TEXT | 表示值是一个文本字符串,使用数据库编码(utf-8 ,utf-16be ,utf-16le )存储 |
BLOB | 表示值是一个数据块,与输入的数据完全相同。 |
由于SQLite采用的是动态数据类型,而其他传统的关系型数据库使用的是静态数据类型,即字段可以存储的数据类型是在表声明时即以确定的,因此它们之间在数据存储方面还是存在着很大的差异。在SQLite中,存储分类和数据类型也有一定的差别,如Integer存储类别可以包含6种不同长度的Integer数据类型,然而这些Integer数据一旦被读入到内存后,SQLite会将其全部视为占用8个字节无符号整型。因此对于SQLite而言,即使在表声明中明确了字段类型,我们仍然可以在该字段中存储其它类型的数据。然而需要特别说明的是,尽管SQLite为我们提供了这种方便,但是一旦考虑到数据库平台的可移植性问题,我们在实际的开发中还是应该尽可能的保证数据类型的存储和声明的一致性。除非你有极为充分的理由,同时又不再考虑数据库平台的移植问题,在此种情况下确实可以使用SQLite提供的此种特征。
1.2、布尔数据类型
SQLite并没有提供专门的布尔存储类型,取而代之的是存储整型1表示true,0表示false。
1.3、日期和时间数据类型
和布尔类型一样,SQLite也同样没有提供专门的日期时间存储类型,而是以TEXT、REAL和INTEGER类型分别不同的格式表示该类型,如:
TEXT: "YYYY-MM-DD HH:MM:SS.SSS"
REAL: 以Julian日期格式存储
INTEGER: 以Unix时间形式保存数据值,即从1970-01-01 00:00:00到当前时间所流经的秒数。
2、亲缘类型:
为了最大化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 | 不做任何的转换,直接以该数据所属的数据类型进行存储。 |
参考
https://www.yiibai.com/sqlite/data-types.html
https://www.cnblogs.com/orangeform/archive/2012/01/18/2325258.html