From 522984283b56b68582d606c76e4ca98c0baf9451 Mon Sep 17 00:00:00 2001 From: MDN Date: Tue, 15 Jun 2021 00:35:40 +0000 Subject: [CRON] sync translated content --- .../basic_concepts_behind_indexeddb/index.html | 210 +++++++++++++++++++++ 1 file changed, 210 insertions(+) create mode 100644 files/zh-tw/orphaned/web/api/indexeddb_api/basic_concepts_behind_indexeddb/index.html (limited to 'files/zh-tw/orphaned') diff --git a/files/zh-tw/orphaned/web/api/indexeddb_api/basic_concepts_behind_indexeddb/index.html b/files/zh-tw/orphaned/web/api/indexeddb_api/basic_concepts_behind_indexeddb/index.html new file mode 100644 index 0000000000..3b9da6d013 --- /dev/null +++ b/files/zh-tw/orphaned/web/api/indexeddb_api/basic_concepts_behind_indexeddb/index.html @@ -0,0 +1,210 @@ +--- +title: IndexedDB基礎概念 +slug: orphaned/Web/API/IndexedDB_API/Basic_Concepts_Behind_IndexedDB +translation_of: Web/API/IndexedDB_API/Basic_Concepts_Behind_IndexedDB +original_slug: Web/API/IndexedDB_API/Basic_Concepts_Behind_IndexedDB +--- +

IndexedDB 用來儲存資料到使用者的瀏覽器，所以我們的網頁應用程式不論在線上或線下都可以運作。IndexedDB 對需要儲存大量資料上 (如儲存 DVD 出租型錄) 的應用和不用一直存取網路的應用 (如郵件客戶端瀏覽、代辦事項、記事本等) 來說十分好用。

+ +

關於本文

+ +

本文介紹 IndexedDB 重要概念和專有名詞，旨在提供 IndexedDB 全貌和關鍵概念，如要了解更多 IndexedDB 專有名詞，請參照定義部分。

+ +

想了解如何使用相關 API，請參照使用 IndexedDB；相關參考資料請參照 IndexedDB 一文，該文介紹了 IndexedDB 使用物件型態以及同步和非同步 API 。

+ +

IndexedDB 概要

+ +

IndexedDB 讓我們透過資料鍵 (key) 儲存、取回物件。所有對資料庫的變更都發生在交易操作；如同大部分網頁儲存方案，IndexedDB 遵守同源政策，也就是說我們只能存取同網域下的資料。

+ +

API 有分非同步和同步，非同步 API 適用於大部分情況，包括 Web Worker，而同步 API 應該只用在 Web Worker 內。目前主流瀏覽器尚不支援同步 API，不過即使同步 API 存在，大部分的情況還是以非同步 API 使用為主。

+ +

W3C 在 2011/11/18 宣布 WebSQL 已棄用，請用 IndexedDB 作為替代方案。IndexedDB 和 WebSQL 雖然都是儲存方案，但功能並不相同，IndexedDB 是索引資料表資料庫，而 WebSQL 是關聯式資料庫系統。

+ +

概念總覽

+ +

請將你在其他類型資料庫上的預期從 IndexedDB 上拋開，然後謹記以下重要概念:

+ + + +

定義

+ +

以下是 IndexedDB API 專有名詞定義與解說。

+ +

Database

+ +
+
資料庫
+
資訊集中存放之處，由一或數個物件存檔 (Object store) 組成，每一個資料庫必須具有: +
    +
  • 名稱。用以辨識資料庫所屬來源，在生命週期間固定不變，可以任意字串 (甚至空白字串) 。
    • +
  • +

    目前版本。當資料庫創建後，如未指定，它的版本是整數1。每一個資料庫同一時間只能有一個版本。

    +
    • +
+
+
物件存檔 (object store)
+
+

資料存放於資料庫的機制；物件存檔持有紀錄，也就是資料鍵和資料值的成對紀錄。記錄在物件存檔中依資料鍵 (keys)大小由小到大排列。

+ +

每一個物件存檔都具備獨特名稱，物件存檔能夠選擇性地持有 key generator 和 key path；若有 key path 便會採用 in-line keys，否則便採用 out-of-line keys。

+ +

更多物件存檔細節，請參照 IDBObjectStore 或 IDBObjectStoreSync。

+
+
版本 (version)
+
當資料庫創建後，如未指定，它的版本是整數 1；每一個資料庫同一時間只能有一個版本，唯一變更版本的方法是開啟比目前更大的版本，變更版本將啟動 versionchange 交易並且觸發 upgradeneeded 事件，upgradeneeded 事件處理器也是唯一可以變更資料庫結構之處。
+
注意: 本處解說涵蓋近期大部分規範，舊版瀏覽器支援現在已經廢棄的 IDBDatabase.setVersion() 方法。
+
 
+
database connection
+
開啟資料庫的作業，一個資料庫同一時間可以擁有多個連線。
+
交易 (transaction)
+
+

在特定資料庫上進行資料存取和資料修改的一連串作業，這便是我們和資料庫的互動，事實上，任何讀取或變更資料庫資料都會發生在交易之中。

+ +

只要寫入交易間沒有重疊範疇 (scopes)，一個資料庫連結可以同時擁有多個進行中交易。交易範疇在交易創建當下決定，交易範疇定義了與交易互動的物件存檔以及將交易期間不可變更部分，例如說，有一個資料庫連結正在進行寫入交易，這項寫入交易涵蓋 flyingMonkey 物件存檔，我們可以進行第二項有關 unicornCentaur 與 unicornPegasus 物件存檔的交易。至於讀取交易則不受交易範疇重疊限制。

+ +

交易的生命應該不可過長，所以瀏覽器可以終止交易時間過長的交易，好讓長時間被鎖定的資料得以解除鎖定；交易可以中止，中止後交易所造成的變更都會被復原；交易的中止不必要等到交易開始或進行中。

+ +

交易有三種模式: readwrite, readonly 和 versionchange，只能透過 versionchange 交易創建、刪除物件存檔與索引。

+ +

由於交易是相當重要的觀念，尤其是交易和版本間的關係，請參照 IDBTransaction 以了解更多交易相
+ 關細節，另外關於同步API，請參照IDBTransactionSync。

+
+
請求 (request)
+
每一個讀寫作業都是一個請求。
+
索引 (index)
+
+

一個用來查詢其他物件存檔內紀錄的特殊物件存檔，被查詢的物件存檔我們稱為參照物件存檔 (referenced object store) 。索引是資料鍵和值的成對紀錄，其中值就是參照物件存檔內的記錄的資料鍵；當參照物件存檔有紀錄新增、變更或刪除時索引內的紀錄也會相應自動產生，索引內的紀錄只能指向參照物件存檔內的一筆紀錄，但可以有多筆索引紀錄參照同一個物件存檔。物件存檔變更同時，所有的相關索引也會自動相應更新。

+ +

除此之外，我們也可以透過資料鍵 (key) 來查詢物件存檔中的紀錄。

+ +

了解如何使用索引請參照使用 IndexedDB，要知道更多索引細節請參照 IDBKeyRange 和 IDBIndex 。

+
+
+ +

資料鍵 (Key) 和資料值 (Value)

+ +
+
資料鍵 (key)
+
+

資料存放在物件存檔中。物件存檔有三種方式產生資料鍵: 資料鍵產生器 (key generator)、資料鍵路徑 (key path) 以及指定值。資料鍵的資料型態 (data type) 必須要是能夠進行大小排序；物件存檔中的每一筆紀錄都要有一支獨特的對應資料鍵，不能和同一個物件存檔中其他紀錄的資料鍵相同。

+ +

資料鍵可以是: string, date, float和 array (陣列)；對於 array，資料鍵範圍可以是空值到無限，還可以在 array 中包含另一個 array，至於以字串或整數作資料鍵則無特殊規定。

+ +

除此之外，我們也可以透過索引 (index) 來查詢物件存檔中的紀錄。

+
+
資料鍵產生器 (key generator)
+
自動生成有大小順序關係的資料鍵的機制；因為資料鍵是必要的，所以如果沒有資料鍵或想省去給定資料鍵的步驟，那就需要用產生器自動產生資料鍵。
+
in-line key
+
當物件存檔有資料鍵路徑時稱為有使用 in-line key。
+
out-of-line key
+
當物件存檔沒有資料鍵路徑時稱為使用 out-of--line key。
+
資料鍵路徑 (key path)
+
定義瀏覽器應該如何從物件存檔資料值或索引中提取資料鍵。以下為有效的資料鍵路徑: 一個空字串、一個 Javascript 辨識名稱 (JavaScript identifier) 或數個由”.”(ASCII字元第46字碼) 分隔的 Javascript 辨識名稱。路徑不可含有空白字元。
+
資料值 (value)
+
+

每筆紀錄都有資料值，資料值可以是任意Javascript所能表達的項目，包括boolean, number, string, date, object, array, regexp, undefined 以及 null。

+ +

儲存物件或陣列裡的屬性和值也可以是任意Javascript所能表達的項目。

+ +

可以儲存 Blobs 和檔案，請參照 W3C 規範。

+
+
+ +

範圍和範疇

+ +
+
範疇
+
交易影響到的物件和索引。讀取交易間的範疇可以互相重疊、同時進行，然後寫入交易範疇則不可，如果同時開啟多項交易範疇相同的寫入交易的話，那麼這些交易會排入佇列 (queue)，一個接著一個完成後執行。
+
指標 (Cursor)
+
在一定資料鍵範圍以內往覆 (iterate) 資料的機制。指標指向了一個物件存檔或索引，它會在一定範圍內，由小到大或由大到小循著紀錄的資料鍵移動，詳細資訊請參照 IDBCursor 或 IDBCursorSync 。
+
資料鍵範圍
+
+

某種資料型態的一段連續區間，這個區間將作為資料鍵的上下限，我們透過資料鍵或資料鍵範圍取出物件存檔和索引值；藉由上下限我們可以做到存取資料鍵介於 x 和 y 之間的資料，詳細請參考 IDBKeyRange 。

+
+
+ +

限制

+ +

IndexedDB 設計上足以滿足大部分客戶端儲存需求，不過，以下情況並不適用 IndexedDB :

+ + + +

除此之外，請小心瀏覽器可能會清空資料庫，例如:

+ + + +

瀏覽器確切的狀況和功能範疇未來會變更，但基本上瀏覽器還是會盡可能保存資料。

+ +

下一步

+ +

現在我們已經了解 IndexedDB 的整體概念，接下來請到 “使用 IndexedDB” 看看如何實際使用 IndexedDB。

+ +

延伸閱讀

+ +

標準規範

+ + + +

參照

+ + + +

相關教學

+ + + +

相關文章

+ + -- cgit v1.2.3-54-g00ecf