全部的应用程序都须要“数据”支持。对于大多数的Web应用程序来讲,数据是在服务器端进行组织和整理,而后由客户端(浏览器端)经过网络请求获取。随着浏览器的处理能力不断加强,能够在浏览器端存储和操纵应用程序须要的数据,所以愈来愈多的网站开始考虑,将大量数据储存在本地客户端,这样能够减小用户等待从服务器端获取数据的时间。javascript
现有的浏览器端数据储存方案,都不适合储存大量数据。Cookie不超过4KB,且每次请求都会发送回服务器端;Window.name属性缺少安全性,且没有统一的标准;LocalStorage容量在2.5MB到10MB之间,且其以字符串形式进行存储。所以,须要一种新的技术解决方案,这就是IndexedDB诞生的背景。html
IndexedDB 是一种浏览器端文档数据库,能够被网页脚本程序建立和操做。它容许储存大量数据,而且提供查询接口,且能够创建索引。这些特性都是localStorage技术所不具有的。就数据库类型而言,IndexedDB不属于关系型数据库(不支持SQL查询语句),更接近NoSQL数据库。关系型数据库(如SQL Server,MySQL,Oracle等)的数据存储在表中;文档数据库(如MongoDB,CouchDB,Redis)将数据集做为个体对象来存储。
经过使用IndexedDB,开发者能够经过惯于在服务器端数据库几乎相同的方式进行建立、读取、更新和删除大量数据记录的操做。前端
IndexedDB具有如下几项特色:
(1) 键值对储存(Key-Value)
IndexedDB内部采用对象仓库(object store)存放数据。全部类型的数据均可以直接存入,包括JavaScript对象。在对象仓库中,数据以“键值对”的形式保存,每个数据都有对应的键名,且键名必须是独一无二的,不能有重复,不然会抛出错误。html5
(2) 异步API(asynchronous API )
IndexedDB数据库在执行增、删、改和查的操做时不会锁死浏览器,用户依然能够进行其它操做。相比之下,localStorage的操做都是同步的。异步设计是为了防止大量数据的读写时拖慢网页,而影响用户的网站体验。java
(3) 支持事务(transaction)
IndexedDB支持事务(transaction),这意味着一系列操做步骤之中,只要有一步失败,整个事务就都取消,数据库回到事务发生以前的状态,不存在只改写一部分数据的状况。git
(4) 同域限制
IndexedDB也受到同域限制,每个数据库对应建立该数据库的域名。来自不一样域名的网页,只能访问自身域名下的数据库,而不能访问其余域名下的数据库。github
(5) 存储空间大
IndexedDB的存储空间比localStorage大得多,通常来讲很多于250MB。IE的储存上限是250MB,Chrome和Opera是硬盘剩余空间的某个百分比,Firefox则没有上限。web
(6) 支持二进制储存
IndexedDB不只能够储存字符串,还能够储存二进制数据。数据库
IndexedDB和LocalStorage都是用来在浏览器里存储数据,但它们使用不一样的技术,有不一样的用途,你须要根据本身的状况适当的选择使用哪一种。api
LocalStorage是用key-value键值模式存储数据,但跟IndexedDB不同的是,它的数据并非按对象形式存储。它存储的数据都是字符串形式。若是你想让LocalStorage存储对象,你须要借助JSON.stringify()能将对象变成字符串形式,再用JSON.parse()将字符串还原成对象。但若是要存储大量的复杂的数据,这并非一种很好的方案。毕竟,localstorage就是专门为小数量数据设计的,它的api是同步的。
IndexedDB很适合存储大量数据,它的API是异步调用的。IndexedDB使用索引存储数据,各类数据库操做放在事务中执行。IndexedDB甚至还支持简单的数据类型。IndexedDB比localstorage强大得多,但它的API也相对复杂。对于简单的数据,你应该继续使用localstorage,但当你但愿存储大量数据时,IndexedDB会明显的更适合,IndexedDB能提供给你更为复杂的查询数据的方式。
WebSQL也是一种在浏览器里存储数据的技术,跟IndexedDB不一样的是,IndexedDB更像是一个NoSQL数据库,而WebSQL更像是关系型数据库,使用SQL查询数据。W3C已经再也不支持这种技术。具体状况请看:http://www.w3.org/TR/webdatabase/。由于再也不支持,因此你就不要在项目中使用这种技术了。
Cookies(小甜点)听起来很好吃,但实际上并非。每次HTTP接受和发送都会传递Cookies数据,它会占用额外的流量。例如,若是你有一个10KB的Cookies数据,发送10次请求,那么,总计就会有100KB的数据在网络上传输。Cookies只能是字符串。浏览器里存储Cookies的空间有限,不少用户禁止浏览器使用Cookies。因此,Cookies只能用来存储小量的非关键的数据。
IndexedDB的架构很像在一些流行的服务器端NoSQL数据库实现中的设计典范类型。面向对象数据经过object stores(对象仓库)进行持久化,全部操做基于请求同时在事务范围内执行;事件生命周期使你可以控制数据库的配置,错误经过错误冒泡来使用API管理。
浏览器原生提供indexedDB对象,能够经过window.indexedDB来直接获取到浏览器提供的该对象,做为开发者的操做接口。IndexedDB.open方法用于打开浏览器本地数据库。
IndexedDB使用事件生命周期管理数据库的打开和配置操做。
对数据库的每次操做,能够描述为经过一个请求打开数据库,访问一个object store,再继续。IndexedDB API天生是基于请求的,这也是异步API本性所示。对于在数据库执行的每次操做,都必须首先为这个操做建立一个请求。当该请求完成,能够响应由请求结果产生的事件或错误。
Object store是IndexedDB数据库的基础。Object store至关于关系型数据库中的一张张记录数据的表。Object stores中包括一个或多个索引(index),在store中按照一对键-值操做,这提供了一种快速定位数据的方法。
不一样于一些传统的关系数据库的实现,每个对数据库操做是在一个事务的上下文中执行的。事务范围一次影响一个或多个object stores,你经过传入一个object store名字的数组到建立事务范围的函数来定义。
建立事务的第二个参数是事务模式。当请求一个事务时,必须决定是按照只读(ReadOnly)仍是读写(ReadWrite)模式请求访问。事务是资源密集型的,因此若是你不须要更改data store中的数据,你只须要以只读模式对object stores集合进行请求访问。
固然,有时候,请求可能不会按预期完成。IndexedDB API经过错误冒泡功能来帮助跟踪和管理错误。若是一个特定的请求遇到错误,你能够尝试在请求对象上处理错误,或者你能够容许错误经过调用栈冒泡向上传递。这个冒泡天性,使得你不须要为每一个请求实现特定错误处理操做,而是能够选择只在一个更高级别上添加错误处理,它给你一个机会,保持你的错误处理代码简洁。
Try……catch机制。
http://www.w3.org/TR/IndexedDB/#dfn-invalidstateerror