IndexedDB技术简介(一)（转）

IndexedDB 是HTML5中的一种数据存储方式。用来帮助网站，在浏览器本地，存储结构比较复杂的数据。它和HTML5中其它的数据存储方式有一些共性：

1.和我们熟知的cookies类似，IndexedDB是每个域名独立存储数据的。
对cookies不熟悉的童鞋，可以顺便学习一下cookies，不过这不影响大家理解IndexedDB。网上cookies的教材和文章非常多，这里不一一列举。

2.和localStorage相比，IndexedDB可以存储任意格式的json object，而localStorage则只能存string，我们在使用localStorage存储复杂数据的时候，常常会协同JSON.parse和JSON.stringify一起工作，而IndexedDB则可以直接存取对象，无需转换成字符串。
对localStorage不熟悉的童鞋，可以查阅w3c官方文档，这里有一份我参与翻译的中文版文档，这里还有一些localStorage的使用建议。

3.和web sql database类似，IndexedDB也分数据库，每个数据库可以建立多个不同配置的表，而且所有的操作都在事务(transaction)中完成，不同之处在于web sql database是通过SQL执行语句来完成操作的，而IndexedDB则直接通过JS API完成操作。
需要指出的是，web sql database规范已经被w3c抛弃，对此不熟的朋友，也不必学习了，如果有童鞋想尝试的，可以找一款webkit浏览器试试看(傲游3、chrome、safari)

IndexedDB的整体存储结构

见下图，IndexedDB(以下简称IDB)严格遵循w3c的同源策略，每个源都拥有独立的大存储空间；每个大存储空间内，又可以通过当前源下的页面脚本创建多个数据库；每个数据库可以包含多个表(ObjectStore)；每个表都是一个json对象列表，可以存储多个json对象，比如{"name": "jinjiang", "age": 26}。


ObjectStore中的key

不同的源、不同的数据库、不同的表、不同的对象，都是如何识别的呢？不同的源直接通过域名进行识别，比如weibo.com、maxthon.cn、renren.com；不同的数据库通过一个字符串(name)识别，比如"blog"、"bbs"、"wiki"等；不同的表也通过一个字符串(name)识别，比如"users"、"contacts"、"articles"等；上面这些识别方式都很好理解，不太好理解的，是如何在表(ObjectStore)中识别不同的json对象，即key。

IDB为ObjectStore提供了两种key：
1.键值对(out-of-line keys: key-value pair)
2.键路径(inline keys: keyPath)

第1种是比较好理解的，就像localStorage中的键值对类似，一个key对应一个value，不同的时，localStorage中的key和value都是字符串类型的，而IDB中的key和value都可以是其它json对象。比如

"a" => "b"
[3, 7] => 21

第2种是通过value中的某个属性字段直接用作key。因为value都是json数据，所以我们可以这样做，假如我们想创建一个表，里面的数据是类似这种感觉的：

{profile: {id: 1, name: "葛优"}, girls: [...]}
{profile: {id: 7, name: "James Bond"}, girls: [...]}
{profile: {id: 8, name: "周星驰"}, girls: [...]}

那么我们就可以把profile里的id作为key，方法是为这个表指定一个keyPath

keyPath => 'profile.id'

这样ObjectStore就会自动按照每个value的value.profile.id进行识别和匹配。

以上就是2种json对象的识别方式。除此之外，我们还可以为ObjectStore加入自增id特性(key generator)，这一特性可以让IDB在添加数据时自动分配一个唯一的key，如果是第2种key，IDB还会把key存在响应的keyPath下。

以上就是对IndexedDB存数结构的介绍，先告一段落。
下一篇文章，会通过简单的接口介绍，帮助大家进一步认识IndexedDB。