所有的应用程序都需要“数据”支持。对于大多数的Web应用程序来说，数据是在服务器端进行组织和整理，然后由客户端（浏览器端）通过网络请求获取。随着浏览器的处理能力不断增强，可以在浏览器端存储和操纵应用程序需要的数据，因此越来越多的网站开始考虑，将大量数据储存在本地客户端，这样可以减少用户等待从服务器端获取数据的时间。
现有的浏览器端数据储存方案，都不适合储存大量数据。Cookie不超过4KB，且每次请求都会发送回服务器端；Window.name属性缺乏安全性，且没有统一的标准；LocalStorage容量在2.5MB到10MB之间，且其以字符串形式进行存储。因此，需要一种新的技术解决方案，这就是IndexedDB诞生的背景。
IndexedDB 是一种浏览器端文档数据库，可以被网页脚本程序创建和操作。它允许储存大量数据，并且提供查询接口，且可以建立索引。这些特性都是localStorage技术所不具备的。就数据库类型而言，IndexedDB不属于关系型数据库（不支持SQL查询语句），更接近NoSQL数据库。关系型数据库（如SQL Server，MySQL，Oracle等）的数据存储在表中；文档数据库（如MongoDB，CouchDB，Redis）将数据集作为个体对象来存储。
通过使用IndexedDB，开发者可以通过惯于在服务器端数据库几乎相同的方式进行创建、读取、更新和删除大量数据记录的操作。
IndexedDB具备以下几项特点：
（1） 键值对储存（Key-Value）
IndexedDB内部采用对象仓库（object store）存放数据。所有类型的数据都可以直接存入，包括JavaScript对象。在对象仓库中，数据以“键值对”的形式保存，每一个数据都有对应的键名，且键名必须是独一无二的，不能有重复，否则会抛出错误。
（2） 异步API（asynchronous API ）
IndexedDB数据库在执行增、删、改和查的操作时不会锁死浏览器，用户依然可以进行其它操作。相比之下，localStorage的操作都是同步的。异步设计是为了防止大量数据的读写时拖慢网页，而影响用户的网站体验。
（3） 支持事务（transaction）
IndexedDB支持事务（transaction），这意味着一系列操作步骤之中，只要有一步失败，整个事务就都取消，数据库回到事务发生之前的状态，不存在只改写一部分数据的情况。
（4） 同域限制
IndexedDB也受到同域限制，每一个数据库对应创建该数据库的域名。来自不同域名的网页，只能访问自身域名下的数据库，而不能访问其他域名下的数据库。
（5） 存储空间大
IndexedDB的存储空间比localStorage大得多，一般来说不少于250MB。IE的储存上限是250MB，Chrome和Opera是硬盘剩余空间的某个百分比，Firefox则没有上限。
（6） 支持二进制储存
IndexedDB不仅可以储存字符串，还可以储存二进制数据。
IndexedDB和LocalStorage都是用来在浏览器里存储数据，但它们使用不同的技术，有不同的用途，你需要根据自己的情况适当的选择使用哪种。
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
原文：http://www.cnblogs.com/weilei92/p/5986154.html