IndexedDB: 瀏覽器里內置的資料庫簡介

一、概述：所有的應用程式都需要“數據”支持。對於大多數的Web應用程式來說，數據是在伺服器端進行組織和整理，然後由客戶端（瀏覽器端）通過網路請求獲取。隨著瀏覽器的處理能力不斷增強，可以在瀏覽器端存儲和操縱應用程式需要的數據，因此越來越多的網站開始考慮，將大量數據儲存在本地客戶端，這樣可以減少用戶等 ...

一、概述：

所有的應用程式都需要“數據”支持。對於大多數的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 VS LocalStorage, Web SQL, Cookies

IndexedDB VS LocalStorage

IndexedDB和LocalStorage都是用來在瀏覽器里存儲數據，但它們使用不同的技術，有不同的用途，你需要根據自己的情況適當的選擇使用哪種。

LocalStorage是用key-value鍵值模式存儲數據，但跟IndexedDB不一樣的是，它的數據並不是按對象形式存儲。它存儲的數據都是字元串形式。如果你想讓LocalStorage存儲對象，你需要藉助JSON.stringify()能將對象變成字元串形式，再用JSON.parse()將字元串還原成對象。但如果要存儲大量的複雜的數據，這並不是一種很好的方案。畢竟，localstorage就是專門為小數量數據設計的，它的api是同步的。

IndexedDB很適合存儲大量數據，它的API是非同步調用的。IndexedDB使用索引存儲數據，各種資料庫操作放在事務中執行。IndexedDB甚至還支持簡單的數據類型。IndexedDB比localstorage強大得多，但它的API也相對複雜。對於簡單的數據，你應該繼續使用localstorage，但當你希望存儲大量數據時，IndexedDB會明顯的更適合，IndexedDB能提供給你更為複雜的查詢數據的方式。

IndexedDB VS Web SQL

WebSQL也是一種在瀏覽器里存儲數據的技術，跟IndexedDB不同的是，IndexedDB更像是一個NoSQL資料庫，而WebSQL更像是關係型資料庫，使用SQL查詢數據。W3C已經不再支持這種技術。具體情況請看：http://www.w3.org/TR/webdatabase/。因為不再支持，所以你就不要在項目中使用這種技術了。

IndexedDB VS Cookies

Cookies(小甜點)聽起來很好吃，但實際上並不是。每次HTTP接受和發送都會傳遞Cookies數據，它會占用額外的流量。例如，如果你有一個10KB的Cookies數據，發送10次請求，那麼，總計就會有100KB的數據在網路上傳輸。Cookies只能是字元串。瀏覽器里存儲Cookies的空間有限，很多用戶禁止瀏覽器使用Cookies。所以，Cookies只能用來存儲小量的非關鍵的數據。

三、IndexedDB架構及技術實現

IndexedDB的架構很像在一些流行的伺服器端NoSQL資料庫實現中的設計典範類型。面向對象數據通過object stores(對象倉庫)進行持久化，所有操作基於請求同時在事務範圍內執行；事件生命周期使你能夠控制資料庫的配置，錯誤通過錯誤冒泡來使用API管理。

IndexedDB之打開資料庫的請求生命周期（Life cycle）

瀏覽器原生提供indexedDB對象，可以通過window.indexedDB來直接獲取到瀏覽器提供的該對象，作為開發者的操作介面。IndexedDB.open方法用於打開瀏覽器本地資料庫。
IndexedDB使用事件生命周期管理資料庫的打開和配置操作。

IndexedDB之基於請求（Request）

對資料庫的每次操作，可以描述為通過一個請求打開資料庫，訪問一個object store，再繼續。IndexedDB API天生是基於請求的，這也是非同步API本性所示。對於在資料庫執行的每次操作，都必須首先為這個操作創建一個請求。當該請求完成，可以響應由請求結果產生的事件或錯誤。

IndexedDB之對象倉庫（Object Store）

Object store是IndexedDB資料庫的基礎。Object store相當於關係型資料庫中的一張張記錄數據的表。Object stores中包括一個或多個索引(index)，在store中按照一對鍵-值操作，這提供了一種快速定位數據的方法。

IndexedDB之一切操作基於事務（Transaction）

不同於一些傳統的關係資料庫的實現，每一個對資料庫操作是在一個事務的上下文中執行的。事務範圍一次影響一個或多個object stores，你通過傳入一個object store名字的數組到創建事務範圍的函數來定義。

創建事務的第二個參數是事務模式。當請求一個事務時，必須決定是按照只讀(ReadOnly)還是讀寫(ReadWrite)模式請求訪問。事務是資源密集型的，所以如果你不需要更改data store中的數據，你只需要以只讀模式對object stores集合進行請求訪問。

IndexedDB之錯誤冒泡

當然，有時候，請求可能不會按預期完成。IndexedDB API通過錯誤冒泡功能來幫助跟蹤和管理錯誤。如果一個特定的請求遇到錯誤，你可以嘗試在請求對象上處理錯誤，或者你可以允許錯誤通過調用棧冒泡向上傳遞。這個冒泡天性，使得你不需要為每個請求實現特定錯誤處理操作，而是可以選擇只在一個更高級別上添加錯誤處理，它給你一個機會，保持你的錯誤處理代碼簡潔。
Try……catch機制。