indexedDB provides a way to store data in the browser using Javascript. Unlike relational databases, indexedDB uses a key-value store that is conceptually similar to HTML5's local storage. However, indexedDB is better than local storage for storing large amounts of data and for querying data more quickly. indexedDB is supported in IE, Chrome, Firefox, and Microsoft Edge, although support for specific features varies.
Overview
The indexedDB standard was created to enable scalable, performant storage and retrieval of Javascript objects in a browser. When using indexedDB, you create an object store, which is essentially a named collection of objects, and then can put objects into the store and later retrieve objects from the store. The store is capable of storing a "large" number of objects. You can also use an index to speed up retrieval.
Prerequisites
Before getting started with indexedDB, there are a couple key points you should consider:
First, indexedDB's API makes significant use of asynchronous functions. You should be familiar with writing asynchronous JavaScript before using indexedDB. A substantial amount of the questions on stackoverflow under the indexedDB tag relate to inexperience with asynchronous functions.
Second, indexedDB serializes objects when saving them. When you save an object in the database, the object itself is not saved. Instead, a serialized representation of the object is saved. This is comparable to using JSON.stringify together with JSON.parse. Therefore, when you retrieve the object from the store, you are retrieving this serialized representation, and not your original object. There are several ramifications of this design. This copy is not your actual object. It is a plain JavaScript object, with properties. Member functions are discarded along with object type information.
Basic concepts
- Database: a container of object stores and indices. Every database has a name and a version.
- Object store: a container of objects. This is analogous to a table in a relational database. In indexedDB, records correspond to Javascript objects, and columns correspond to Javascript object properties. Objects added to the store are stored in the order added. Queries against the store retrieve objects in the same order. You can insert, update, or delete objects in an object store.
- Index: a special container for specific objects contained within an object store. Indices are also analogous to tables, and can be understood as object stores with special constraints. When an object is inserted into an object store, it may, if it meets certain criteria, also be inserted into a corresponding index store. Objects in an index are stored in an order defined by the index. Queries against an index retrieve objects in the order defined by the index (although queries can be configured to work differently). You cannot insert, update, or delete objects in an index (you can only do so indirectly by inserting the object into the store upon which the index is based).
- Cursor: cursors are analogous to queries. A cursor iterates over the objects in either an object store or an index. Cursors can move forwards or backwards, seek (jump or advance past objects), and jump to the next or previous 'unique' object in the underlying store/index.
- Key path: key paths are analogous to primary keys (or compound primary keys) of a table in a relational database. In the general case, when you instruct indexedDB to create an object store in a particular database, you also define the key path for the store. You can use the key path to quickly get a particular object, which is similar to using a primary key to select a record in a relational table. You can, optionally, use keys to ensure that later attempts to insert an object into an object store that already contains an object with the same key will produce an error.
- Transactions and requests: requests are analogous to individual SQL queries. There are specific API methods for inserting an object, deleting an object, updating an object, and iterating over one or more objects. Each method call corresponds to a single request. Each request occurs within the context of a transaction. In other words, multiple requests can occur in one transaction. Individual requests can fail for a variety of reasons. When performing multiple requests in a single transaction, the requests are not fully committed until all the requests are considered successful. In this manner, if a problem occurs in a later request, the entire transaction can be "rolled back" so that the state of the underlying object store is the same as it was before the occurrence of the first request in the transaction.
Support
Visit http://caniuse.com/#feat=indexeddb.
