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 --- files/ko/_redirects.txt | 3 +- files/ko/_wikihistory.json | 30 +-- .../basic_concepts_behind_indexeddb/index.html | 224 +++++++++++++++++++++ .../basic_concepts_behind_indexeddb/index.html | 223 -------------------- 4 files changed, 241 insertions(+), 239 deletions(-) create mode 100644 files/ko/orphaned/web/api/indexeddb_api/basic_concepts_behind_indexeddb/index.html delete mode 100644 files/ko/web/api/indexeddb_api/basic_concepts_behind_indexeddb/index.html (limited to 'files/ko') diff --git a/files/ko/_redirects.txt b/files/ko/_redirects.txt index 9340068327..5cb2285f1b 100644 --- a/files/ko/_redirects.txt +++ b/files/ko/_redirects.txt @@ -328,7 +328,7 @@ /ko/docs/HTML:Element:a /ko/docs/Web/HTML/Element/a /ko/docs/HTML:Inline_elements /ko/docs/Web/HTML/Inline_elements /ko/docs/IndexedDB /ko/docs/Web/API/IndexedDB_API -/ko/docs/IndexedDB/Basic_Concepts_Behind_IndexedDB /ko/docs/Web/API/IndexedDB_API/Basic_Concepts_Behind_IndexedDB +/ko/docs/IndexedDB/Basic_Concepts_Behind_IndexedDB /ko/docs/orphaned/Web/API/IndexedDB_API/Basic_Concepts_Behind_IndexedDB /ko/docs/IndexedDB/Using_IndexedDB /ko/docs/Web/API/IndexedDB_API/Using_IndexedDB /ko/docs/Introduction_to_using_XPath_in_JavaScript /ko/docs/Web/XPath/Introduction_to_using_XPath_in_JavaScript /ko/docs/JSAPI_Reference/Alphabetical_List /ko/docs/JSAPI_Reference @@ -626,6 +626,7 @@ /ko/docs/Web/API/HTMLHyperlinkElementUtils/href /ko/docs/Web/API/HTMLAnchorElement/href /ko/docs/Web/API/HTML_드래그_앤_드롭_API /ko/docs/Web/API/HTML_Drag_and_Drop_API /ko/docs/Web/API/HTML_드래그_앤_드롭_API/Drag_operations /ko/docs/Web/API/HTML_Drag_and_Drop_API/Drag_operations +/ko/docs/Web/API/IndexedDB_API/Basic_Concepts_Behind_IndexedDB /ko/docs/orphaned/Web/API/IndexedDB_API/Basic_Concepts_Behind_IndexedDB /ko/docs/Web/API/Navigator.battery /ko/docs/Web/API/Navigator/battery /ko/docs/Web/API/Navigator.battery/window.navigator.battery /ko/docs/Web/API/Navigator/battery /ko/docs/Web/API/Navigator.connection/window.navigator.connection /ko/docs/Web/API/Navigator/connection diff --git a/files/ko/_wikihistory.json b/files/ko/_wikihistory.json index bb0efda708..4322628e68 100644 --- a/files/ko/_wikihistory.json +++ b/files/ko/_wikihistory.json @@ -5594,21 +5594,6 @@ "claudepache" ] }, - "Web/API/IndexedDB_API/Basic_Concepts_Behind_IndexedDB": { - "modified": "2020-12-08T00:45:03.205Z", - "contributors": [ - "dsma73", - "chrisdavidmills", - "alattalatta", - "LostCatLee", - "daesD", - "naduhy2", - "bingl2", - "nacyot", - "fscholz", - "JoonghunPark" - ] - }, "Web/API/IndexedDB_API/Using_IndexedDB": { "modified": "2020-07-21T23:16:52.351Z", "contributors": [ @@ -18367,6 +18352,21 @@ "connorshea" ] }, + "orphaned/Web/API/IndexedDB_API/Basic_Concepts_Behind_IndexedDB": { + "modified": "2020-12-08T00:45:03.205Z", + "contributors": [ + "dsma73", + "chrisdavidmills", + "alattalatta", + "LostCatLee", + "daesD", + "naduhy2", + "bingl2", + "nacyot", + "fscholz", + "JoonghunPark" + ] + }, "orphaned/Web/API/OffscreenCanvas/toBlob": { "modified": "2020-10-15T22:14:42.795Z", "contributors": [ diff --git a/files/ko/orphaned/web/api/indexeddb_api/basic_concepts_behind_indexeddb/index.html b/files/ko/orphaned/web/api/indexeddb_api/basic_concepts_behind_indexeddb/index.html new file mode 100644 index 0000000000..637c74a373 --- /dev/null +++ b/files/ko/orphaned/web/api/indexeddb_api/basic_concepts_behind_indexeddb/index.html @@ -0,0 +1,224 @@ +--- +title: 기본 개념 +slug: orphaned/Web/API/IndexedDB_API/Basic_Concepts_Behind_IndexedDB +tags: + - Advanced + - IndexedDB +translation_of: Web/API/IndexedDB_API/Basic_Concepts_Behind_IndexedDB +original_slug: Web/API/IndexedDB_API/Basic_Concepts_Behind_IndexedDB +--- +

{{DefaultAPISidebar("IndexedDB")}}

+ +
+

IndexedDB는 사용자의 브라우저 안에 데이터를 영구적으로 저장하게 해주는 방법 중 하나입니다. 그것은 네트워크 가능 여부에 상관없이, 풍부한 쿼리 작성 능력으로 웹 애플리케이션을 만들게 해주고, 이 애플리케이션은 온라인과 오프라인 모두에서 동작할 수 있습니다. IndexedDB는 예를 들면, 도서관의 DVD 목록처럼 대용량 데이터를 저장하는 애플리케이션, 그리고 메일 클라이언트, to-do 리스트, 노트패드처럼 동작에 지속적인 인터넷 연결이 필요하지 않은 애플리케이션에 유용합니다.

+
+ +

이 문서에 대하여

+ +

이 소개글은 IndexedDB의 필수 개념과 용어에 대해 논의합니다. 큰 그림을 제공하고 핵심 개념들을 설명합니다.

+ +

다음과 같은 유용한 정보를 찾을 수 있을 것입니다.

+ + + +

IndexedDB 개요

+ +

IndexedDB는 "키(key)"로 지정된 객체를 저장하고 검색할 수 있도록 도와줍니다. 데이터베이스에 적용하는 모든 변경은 트렌잭션 안에서 일어납니다. 대부분의 웹 스토리지 솔루션과 마찬가지로, IndexedDB는 동일 출처 정책 (same-origin policy)을 따릅니다. 따라서 당신이 한 도메인의 데이터에 접근하고 있는 동안, 다른 도메인의 데이터에 접근할 수 없습니다.

+ +

IndexedDB는 웹 워커를 포함하는 대부분의 문맥(컨텍스트)에 사용될 수 있는 비동기(asynchronous) API입니다. 웹 워커에서 사용하기 위해 동기(synchronous) 버전도 존재했지만, 웹 커뮤니티의 관심부족으로 웹 스펙에서 제거되었습니다.

+ +

IndexedDB는 WebSQL 데이터베이스와 경쟁 관계에 있었지만, W3C는 2010 11월 8일에 WebSQL을 폐기(deprecated)하였습니다. IndexedDB와 WebSQL 모두 데이터 저장을 위한 솔루션이지만, 동일한 기능을 제공하지는 않습니다. WebSQL Database는 관계형 데이터베이스 접근 시스템인 반면, IndexedDB는 인덱스 테이블 시스템입니다.

+ +

주요 개념들

+ +

만약 당신이 다른 DB 시스템을 사용해봤던 경험이 있다면 오히려 잘못된 추측으로 인해 IndexedDB로 작업할 때 힘들어질 수도 있습니다. 그러므로 다음의 중요한 개념들을 잘 정리해 두어야 합니다.

+ + + +

정의

+ +

이 섹션은 IndexedDB API에서 사용되는 용어들을 정의하고 설명합니다.

+ +

데이터베이스

+ +
+
데이터베이스
+
일반적으로 하나 혹은 그 이상의 객체 저장소로 구성되는 정보의 레파지토리입니다. 개별 데이터베이스는 다음의 내용을 반드시 가져야 합니다. +
    +
  • 이름(Name). 이것은 하나의 특정 출처 내에서 database를 구별하고 데이터베이스가 존재하는 동안 일정하게 유지됩니다. 이름은 빈 문자열을 포함해서 어떤 문자열 값이라도 될 수 있습니다.
    • +
  • +

    현재 버전. 데이터베이스가 처음 만들어질 때, 따로 지정하지 않으면 버전은 정수 1입니다. 각 데이터베이스는 주어진 순간에 오직 하나의 버전을 가질 수 있습니다.

    +
    • +
+
+
지속성
+
+

파이어폭스에서 indexedDB는 지속성을 유지하기 위해 사용됩니다. 즉, 읽기쓰기 트랜젝션{{domxref("IDBTransaction.oncomplete")}}이 모든 데이터가 디스크로 들어갈 수 있도록 보장될 때에만 실행됩니다.

+ +

파이어폭스 40에서, IndexedDB 트랜젝션은 성능을 높이기 위해 지속성 보장을 늦춰왔는데, 이는 IndexedDB를 지원하는 다른 브라우저도 동일한 방식입니다{{Bug("1112702")}}. 이 경우 {{Event("complete")}} 이벤트는 OS가 데이터 쓰기를 하라고 전달한 후, 데이터가 실제로 데이터베이스에 반영되기 전에 잠재적으로 실행됩니다. 이벤트는 이전보다 더 빠르게 전달될지도 모르지만, 만약 OS가 다운되거나 데이터가 데이터베이스에 반영되기 전에 시스템 전원이 부족하면, 전체 트랜젝션은 잃게 될 수도 있는 희박한 위험성이 존재합니다. 그런 치명적인 이벤트는 드물기 때문에, 대부분의 소비자는 더 이상 염려할 필요는 없습니다.

+ +
+

Note: 파이어폭스에서 (나중에 다시 계산 할 수 없는 까다로운 데이터를 저장하는 것)과 같은 몇 가지 이유로 지속성을 보장하고 싶다면, complete 이벤트가 전달되기 전에 아직 정식 표준이 아닌 실험적인 readwriteflush 모드를 이용하여 트랜젝션을 데이터베이스에 강제로 반영할 수 있습니다. ({{domxref("IDBDatabase.transaction")}} 참고.) 현재는 실험적으로 적용되어 있고(experimental), about:config에서dom.indexedDB.experimental값이 true 로 설정되어 있을 때만 사용할 수 있습니다.

+
+
+
객체 저장소 ( Object Store )
+
+

데이터베이스에 데이터가 저장되는 매커니즘입니다. 객체 저장소는 키(key)와 값(value)의 쌍으로 된 레코드를 영구적으로 잡습니다. 한 객체 저장소 안의 레코드는 키(key)에 따라 오름차순으로 정렬됩니다.

+ +

모든 객체 저장소는 데이터베이스 안에서 고유한 이름을 가져야 합니다. 객체 저장소는 선택적으로 key generator와 key path를 가질 수 있습니다. 만약 객체 저장소가 key path를 가진다면, 그것은 in-line keys를 사용합니다.  아니면, 그것은 out-of-line keys를 사용하는 것입니다.

+ +

객체 저장소에 대한 보다 자세한 정보는, IDBObjectStore 또는 IDBObjectStoreSync를 참조하세요.

+
+
version
+
Database가 처음 만들어질 때, version은 정수형 숫자로 1입니다. 각 database는  하나의 version을 집니다; 하나의 데이터베이스가 한번에 여러 version으로 존재할 수 없다. version을 바꾸는 유일한 방법은 현재 버전보다 큰 버전으로 그것을 여는 것입니다. 이렇ㄱ하면 versionchange 트랜잭션을 시작하고 upgradeneeded event를 발생시킵니다. database의 schema를 변경하려면 upgradeneed 이벤트 핸들러내에서 수행해야 합니다.
+
Note: 이 스펙은  most recent specification, which is only implemented in up-to-date browsers. Old browsers implemented the now deprecated and removed IDBDatabase.setVersion() method.
+
database connection
+
 database를 여는 것에 의해 생성되는 operation. 한 주어진 database는 동시에 여러개의 connections를 가질 수 있다.
+
transaction
+
+

특정 database에 대한 data-access와 data-modification operations의 원자적이고 견고한 집합. 그것이 database에서 당신이 data로 상호작용하는 방법이다. 사실, database에서의 어떠한 data의 읽기 또는 변경도 transaction 내에서 일어나야 한다.

+ +

하나의 database connection은 한번에 그에 연관된 여러 active transaction을 가질 수 있다, writing transactions이 겹치는 scopes을 갖지 않는 동안. 생성에서 정의되는  transactions의 scope은 그 transaction이 어느 object stores와 상호작용할 수 있는지를 결정하고 그 transaction의 lifetime동안 일정하다. 따라서, 예를 들어, 만약 한 database connection이 flyingMonkey object store를 커버하는 scope의 writing transaction을 이미 가지면, 당신은  unicornCentaur과 unicornPegasus object stores의 scope을 가진 두번째 transaction을 시작할 수 있다. reading transactions로서, 당신은 여러개를 가질 수 있다 — 심지어 겹치는 것들이라도.

+ +

Transactions는 short-lived일 것이 기대된다, 그래서 브라우저는 너무 오래걸리는 transaction을 종료할 수 있다, 그 long-running transaction이 lock한 storage resources를 해제하기 위해. 당신은 transaction을 abort할 수 있다 , 이는 그 transaction에서 만들어진 변경들을 roll back한다. 그리고 당신은 심지어 transaction을 abort하기 위해 그것이 시작되거나 활성화되기를 기다릴 필요가 없다.

+ +

Transaction의 세가지 모드는: readwrite, readonly, 그리고 versionchange. Object stores와 indexes를 생성하는 유일한 방법은 versionchange transaction을 이용하는 것이다. transaction types를 더 배우기 위해, IndexedDB에 대한 reference article을 보라.

+ +

모든 것은 하나의 transaction에서 일어나기 때문에, IndexedDB에서 그것은 매우 중요한 개념이다. transactions에 대해 더 배우기 위해, 특히 그것들이 어떻게 versioning과 관련되는가에 대해, IDBTransaction를 보라, 그는 또한 reference documentation을 가진다. synchronous API에 대한 문서를 위해, IDBTransactionSync를 보라.

+
+
request
+
database에 읽고 쓰기를 행하는 operation. 모든 request는 하나의 읽기 혹은 쓰기 operation을 나타낸다.
+
index
+
+

하나의 index는 다른 object store의 records를 찾기 위한 specialized object store이다, referenced object store라 불리는. index는 그 records의 value part가 referenced object store의 한 record의 key part인 영구적인 key-value storage이다. 하나의 index의 records는 referenced object안에 record가 삽입되고 update되고 삭제될 때마다 자동적으로 생성된다. 하나의 index의 각 record는 그의 referenced object store의 오직 하나의 record를 가리킬 수 있다, 그러나 여러 indexes가 같은 object store를 참조할 수 있다. object store가 변할 때, 그 object store를 참조하는 모든 index는 자동으로 update된다.

+ +

다른 방법으로, key를 사용해서 object store에서 records를 찾을 수 있다.

+ +

indexes 사용하기에 대해 더 배우기 위해, Using IndexedDB를 보라. index에 대한 reference documentation을 위해, IDBKeyRange를 보라.

+
+
+ +

Key and value

+ +
+
key
+
+

object store에서 이에 의해 저장된 values가 조직되고 조회되는 하나의 data value. object store는 세 sources 중 하나로부터 key를 이끌어낼 수 있다: key generator, key path, 또는 명시적으로 지정된 value. key는 그 앞에 있는 것보다 큰 값을 지닌 한 data type의 것이어야 한다. object store의 각 record는 같은 store 내에서 유일한 key를 가져야 한다, 따라서 당신은 주어진 object store에서 같은 key의 여러 records를 가질 수 없다.

+ +

하나의 key는 다음의 types 중 하나가 될 수 있다: string, date, float, 그리고 array. arrays에 대해, key는 empty value로부터 infinity의 범위가 될 수 있다. 그리고 당신은 array 내에 array를 포함할 수 있다. string 또는 integer의 key만 사용해야 한다는 요구사항은 없다.

+ +

다른 방법으로, 당신은 index를 사용해서 object store에서 records를 찾을 수 있다.

+
+
key generator
+
정렬 sequence로 새 keys를 생성하기 위한 mechanism. 만약 한 object store가 key generator를 가지지 않으면, application은 저장되는 records를 위한 keys를 제공해야 한다. Generators는 stores 간에 공유되지 않는다. 이것은 브라우저 구현 세부사항에 가깝다, 때문에 web 개발에서, 당신은 실제로 key generators를 만들고 접근할 필요가 없다.
+
in-line key
+
저장되는 value의 부분으로서 저장되는 key. key path를 사용함으로써 찾아진다. 하나의 in-line key는 generator를 이용해서 생성될 수 있다. key가 생성된 후에, 그것은 key path를 사용하는 value에 저장될 수 있거나 key로서 사용될 수 있다.
+
out-of-line key
+
저장되는 value와는 따로 저장되는 key.
+
key path
+
object store 또는 index에서 브라우저가 어디로부터 key를 추출해야 하는지 정의한다. 하나의 valid key path는 다음 중 하나를 포함할 수 있다: an empty string, a JavaScript identifier, or multiple JavaScript identifiers separated by periods. 그것은 spaces를 포함할 수 없다.
+
value
+
+

각각의 record는 하나의 value를 가진다, 이는 javascript로 표현될 수 있는 어떤 것이라도 포함할 수 있다, boolean, number, string, date, object, array, regexp, undefined, 그리고 null을 포함해서.

+ +

object 또는 array가 저장될 때, 그 object 또는 array의  properties 와 values는 적합한 어떤 값이라도 될 수 있다.

+ +

Blobs와 files가 저장될 수 있다, cf. specification.

+
+
+ +

Range and scope

+ +
+
scope
+
한 transaction이 적용되는 object stores와 indexe. read-only transactions의 scope은 겹칠 수 있고 동시에 실행될 수 있다. 한편으로, writing transactions의 scope은 겹칠 수 없다. 당신은 여전히 동시에 같은 scope의 여러 transaction을 실행할 수 있지만 그들은 queue up하고 하나하나 차례로 실행된다.
+
cursor
+
한 key range의 여러 records에 대한 iterating을 위한 mechanism. The cursor는 그것이 iterating하는 것이 어느 index또는 object store인지 가리키는 한 source를 가진다. 그것은 그 range 내의 position을 가지고, record keys의 순서에서 증가 혹은 감소하는 한 방향으로 움직인다. cursors에 대한 reference documentation을 위해, IDBCursor 또는 IDBCursorSync를 보라.
+
key range
+
+

keys를 위해 사용되는 몇몇 data type에 대한 하나의 연속 구간. Records는 keys 또는 하나의 range of keys를 사용하는 object sotres와 indexes로부터 조회될 수 있다. 당신은 lower 그리고 upper bound를 사용해서 range를 제한하거나 걸러낼 수 있다. 예를 들어, 당신은 x와 y 사이의 한 key의 모든 값에 대해 iterate할 수 있다.

+ +

key range에 대한 reference documentation을 위해, IDBKeyRange를 보라.

+
+
+ +

한계점들

+ +

IndexedDB는 client-side storage가 필요한 대부분의 경우를 해결하기 위해 만들어졌다. 하지만 그것은 다음과 같은 몇 가지 경우를 해결하진 못 한다:

+ + + +

덧붙여서, 다음과 같은 조건에서 브라우저가 데이터베이스를 지울 수 있음을 알아두라:

+ + + +

정확한 삭제 시점과 브라우져의 DB 수용능력은 때때로 달라질 수 있습니다만, 브라우져 벤더가 지킬려고 노력하는 가장 기본적인 철학은 데이터를 가능한 최대한 데이터를 지킬려고 노력한다는 것입니다.

+ +

Next steps

+ +

이제 큰 그림은 이해할 수 있게 됐고 아울러 보다 복잡한 사용법을 익힐 준비가 됐네요. 실제로 어떻게 API를 사용하는지 알아보기 위해서, Using IndexedDB를 살펴봅시다.

+ +

함께 보기

+ + + + + + + +
+
+
diff --git a/files/ko/web/api/indexeddb_api/basic_concepts_behind_indexeddb/index.html b/files/ko/web/api/indexeddb_api/basic_concepts_behind_indexeddb/index.html deleted file mode 100644 index c3d95b2eac..0000000000 --- a/files/ko/web/api/indexeddb_api/basic_concepts_behind_indexeddb/index.html +++ /dev/null @@ -1,223 +0,0 @@ ---- -title: 기본 개념 -slug: Web/API/IndexedDB_API/Basic_Concepts_Behind_IndexedDB -tags: - - Advanced - - IndexedDB -translation_of: Web/API/IndexedDB_API/Basic_Concepts_Behind_IndexedDB ---- -

{{DefaultAPISidebar("IndexedDB")}}

- -
-

IndexedDB는 사용자의 브라우저 안에 데이터를 영구적으로 저장하게 해주는 방법 중 하나입니다. 그것은 네트워크 가능 여부에 상관없이, 풍부한 쿼리 작성 능력으로 웹 애플리케이션을 만들게 해주고, 이 애플리케이션은 온라인과 오프라인 모두에서 동작할 수 있습니다. IndexedDB는 예를 들면, 도서관의 DVD 목록처럼 대용량 데이터를 저장하는 애플리케이션, 그리고 메일 클라이언트, to-do 리스트, 노트패드처럼 동작에 지속적인 인터넷 연결이 필요하지 않은 애플리케이션에 유용합니다.

-
- -

이 문서에 대하여

- -

이 소개글은 IndexedDB의 필수 개념과 용어에 대해 논의합니다. 큰 그림을 제공하고 핵심 개념들을 설명합니다.

- -

다음과 같은 유용한 정보를 찾을 수 있을 것입니다.

- - - -

IndexedDB 개요

- -

IndexedDB는 "키(key)"로 지정된 객체를 저장하고 검색할 수 있도록 도와줍니다. 데이터베이스에 적용하는 모든 변경은 트렌잭션 안에서 일어납니다. 대부분의 웹 스토리지 솔루션과 마찬가지로, IndexedDB는 동일 출처 정책 (same-origin policy)을 따릅니다. 따라서 당신이 한 도메인의 데이터에 접근하고 있는 동안, 다른 도메인의 데이터에 접근할 수 없습니다.

- -

IndexedDB는 웹 워커를 포함하는 대부분의 문맥(컨텍스트)에 사용될 수 있는 비동기(asynchronous) API입니다. 웹 워커에서 사용하기 위해 동기(synchronous) 버전도 존재했지만, 웹 커뮤니티의 관심부족으로 웹 스펙에서 제거되었습니다.

- -

IndexedDB는 WebSQL 데이터베이스와 경쟁 관계에 있었지만, W3C는 2010 11월 8일에 WebSQL을 폐기(deprecated)하였습니다. IndexedDB와 WebSQL 모두 데이터 저장을 위한 솔루션이지만, 동일한 기능을 제공하지는 않습니다. WebSQL Database는 관계형 데이터베이스 접근 시스템인 반면, IndexedDB는 인덱스 테이블 시스템입니다.

- -

주요 개념들

- -

만약 당신이 다른 DB 시스템을 사용해봤던 경험이 있다면 오히려 잘못된 추측으로 인해 IndexedDB로 작업할 때 힘들어질 수도 있습니다. 그러므로 다음의 중요한 개념들을 잘 정리해 두어야 합니다.

- - - -

정의

- -

이 섹션은 IndexedDB API에서 사용되는 용어들을 정의하고 설명합니다.

- -

데이터베이스

- -
-
데이터베이스
-
일반적으로 하나 혹은 그 이상의 객체 저장소로 구성되는 정보의 레파지토리입니다. 개별 데이터베이스는 다음의 내용을 반드시 가져야 합니다. -
    -
  • 이름(Name). 이것은 하나의 특정 출처 내에서 database를 구별하고 데이터베이스가 존재하는 동안 일정하게 유지됩니다. 이름은 빈 문자열을 포함해서 어떤 문자열 값이라도 될 수 있습니다.
    • -
  • -

    현재 버전. 데이터베이스가 처음 만들어질 때, 따로 지정하지 않으면 버전은 정수 1입니다. 각 데이터베이스는 주어진 순간에 오직 하나의 버전을 가질 수 있습니다.

    -
    • -
-
-
지속성
-
-

파이어폭스에서 indexedDB는 지속성을 유지하기 위해 사용됩니다. 즉, 읽기쓰기 트랜젝션{{domxref("IDBTransaction.oncomplete")}}이 모든 데이터가 디스크로 들어갈 수 있도록 보장될 때에만 실행됩니다.

- -

파이어폭스 40에서, IndexedDB 트랜젝션은 성능을 높이기 위해 지속성 보장을 늦춰왔는데, 이는 IndexedDB를 지원하는 다른 브라우저도 동일한 방식입니다{{Bug("1112702")}}. 이 경우 {{Event("complete")}} 이벤트는 OS가 데이터 쓰기를 하라고 전달한 후, 데이터가 실제로 데이터베이스에 반영되기 전에 잠재적으로 실행됩니다. 이벤트는 이전보다 더 빠르게 전달될지도 모르지만, 만약 OS가 다운되거나 데이터가 데이터베이스에 반영되기 전에 시스템 전원이 부족하면, 전체 트랜젝션은 잃게 될 수도 있는 희박한 위험성이 존재합니다. 그런 치명적인 이벤트는 드물기 때문에, 대부분의 소비자는 더 이상 염려할 필요는 없습니다.

- -
-

Note: 파이어폭스에서 (나중에 다시 계산 할 수 없는 까다로운 데이터를 저장하는 것)과 같은 몇 가지 이유로 지속성을 보장하고 싶다면, complete 이벤트가 전달되기 전에 아직 정식 표준이 아닌 실험적인 readwriteflush 모드를 이용하여 트랜젝션을 데이터베이스에 강제로 반영할 수 있습니다. ({{domxref("IDBDatabase.transaction")}} 참고.) 현재는 실험적으로 적용되어 있고(experimental), about:config에서dom.indexedDB.experimental값이 true 로 설정되어 있을 때만 사용할 수 있습니다.

-
-
-
객체 저장소 ( Object Store )
-
-

데이터베이스에 데이터가 저장되는 매커니즘입니다. 객체 저장소는 키(key)와 값(value)의 쌍으로 된 레코드를 영구적으로 잡습니다. 한 객체 저장소 안의 레코드는 키(key)에 따라 오름차순으로 정렬됩니다.

- -

모든 객체 저장소는 데이터베이스 안에서 고유한 이름을 가져야 합니다. 객체 저장소는 선택적으로 key generator와 key path를 가질 수 있습니다. 만약 객체 저장소가 key path를 가진다면, 그것은 in-line keys를 사용합니다.  아니면, 그것은 out-of-line keys를 사용하는 것입니다.

- -

객체 저장소에 대한 보다 자세한 정보는, IDBObjectStore 또는 IDBObjectStoreSync를 참조하세요.

-
-
version
-
Database가 처음 만들어질 때, version은 정수형 숫자로 1입니다. 각 database는  하나의 version을 집니다; 하나의 데이터베이스가 한번에 여러 version으로 존재할 수 없다. version을 바꾸는 유일한 방법은 현재 버전보다 큰 버전으로 그것을 여는 것입니다. 이렇ㄱ하면 versionchange 트랜잭션을 시작하고 upgradeneeded event를 발생시킵니다. database의 schema를 변경하려면 upgradeneed 이벤트 핸들러내에서 수행해야 합니다.
-
Note: 이 스펙은  most recent specification, which is only implemented in up-to-date browsers. Old browsers implemented the now deprecated and removed IDBDatabase.setVersion() method.
-
database connection
-
 database를 여는 것에 의해 생성되는 operation. 한 주어진 database는 동시에 여러개의 connections를 가질 수 있다.
-
transaction
-
-

특정 database에 대한 data-access와 data-modification operations의 원자적이고 견고한 집합. 그것이 database에서 당신이 data로 상호작용하는 방법이다. 사실, database에서의 어떠한 data의 읽기 또는 변경도 transaction 내에서 일어나야 한다.

- -

하나의 database connection은 한번에 그에 연관된 여러 active transaction을 가질 수 있다, writing transactions이 겹치는 scopes을 갖지 않는 동안. 생성에서 정의되는  transactions의 scope은 그 transaction이 어느 object stores와 상호작용할 수 있는지를 결정하고 그 transaction의 lifetime동안 일정하다. 따라서, 예를 들어, 만약 한 database connection이 flyingMonkey object store를 커버하는 scope의 writing transaction을 이미 가지면, 당신은  unicornCentaur과 unicornPegasus object stores의 scope을 가진 두번째 transaction을 시작할 수 있다. reading transactions로서, 당신은 여러개를 가질 수 있다 — 심지어 겹치는 것들이라도.

- -

Transactions는 short-lived일 것이 기대된다, 그래서 브라우저는 너무 오래걸리는 transaction을 종료할 수 있다, 그 long-running transaction이 lock한 storage resources를 해제하기 위해. 당신은 transaction을 abort할 수 있다 , 이는 그 transaction에서 만들어진 변경들을 roll back한다. 그리고 당신은 심지어 transaction을 abort하기 위해 그것이 시작되거나 활성화되기를 기다릴 필요가 없다.

- -

Transaction의 세가지 모드는: readwrite, readonly, 그리고 versionchange. Object stores와 indexes를 생성하는 유일한 방법은 versionchange transaction을 이용하는 것이다. transaction types를 더 배우기 위해, IndexedDB에 대한 reference article을 보라.

- -

모든 것은 하나의 transaction에서 일어나기 때문에, IndexedDB에서 그것은 매우 중요한 개념이다. transactions에 대해 더 배우기 위해, 특히 그것들이 어떻게 versioning과 관련되는가에 대해, IDBTransaction를 보라, 그는 또한 reference documentation을 가진다. synchronous API에 대한 문서를 위해, IDBTransactionSync를 보라.

-
-
request
-
database에 읽고 쓰기를 행하는 operation. 모든 request는 하나의 읽기 혹은 쓰기 operation을 나타낸다.
-
index
-
-

하나의 index는 다른 object store의 records를 찾기 위한 specialized object store이다, referenced object store라 불리는. index는 그 records의 value part가 referenced object store의 한 record의 key part인 영구적인 key-value storage이다. 하나의 index의 records는 referenced object안에 record가 삽입되고 update되고 삭제될 때마다 자동적으로 생성된다. 하나의 index의 각 record는 그의 referenced object store의 오직 하나의 record를 가리킬 수 있다, 그러나 여러 indexes가 같은 object store를 참조할 수 있다. object store가 변할 때, 그 object store를 참조하는 모든 index는 자동으로 update된다.

- -

다른 방법으로, key를 사용해서 object store에서 records를 찾을 수 있다.

- -

indexes 사용하기에 대해 더 배우기 위해, Using IndexedDB를 보라. index에 대한 reference documentation을 위해, IDBKeyRange를 보라.

-
-
- -

Key and value

- -
-
key
-
-

object store에서 이에 의해 저장된 values가 조직되고 조회되는 하나의 data value. object store는 세 sources 중 하나로부터 key를 이끌어낼 수 있다: key generator, key path, 또는 명시적으로 지정된 value. key는 그 앞에 있는 것보다 큰 값을 지닌 한 data type의 것이어야 한다. object store의 각 record는 같은 store 내에서 유일한 key를 가져야 한다, 따라서 당신은 주어진 object store에서 같은 key의 여러 records를 가질 수 없다.

- -

하나의 key는 다음의 types 중 하나가 될 수 있다: string, date, float, 그리고 array. arrays에 대해, key는 empty value로부터 infinity의 범위가 될 수 있다. 그리고 당신은 array 내에 array를 포함할 수 있다. string 또는 integer의 key만 사용해야 한다는 요구사항은 없다.

- -

다른 방법으로, 당신은 index를 사용해서 object store에서 records를 찾을 수 있다.

-
-
key generator
-
정렬 sequence로 새 keys를 생성하기 위한 mechanism. 만약 한 object store가 key generator를 가지지 않으면, application은 저장되는 records를 위한 keys를 제공해야 한다. Generators는 stores 간에 공유되지 않는다. 이것은 브라우저 구현 세부사항에 가깝다, 때문에 web 개발에서, 당신은 실제로 key generators를 만들고 접근할 필요가 없다.
-
in-line key
-
저장되는 value의 부분으로서 저장되는 key. key path를 사용함으로써 찾아진다. 하나의 in-line key는 generator를 이용해서 생성될 수 있다. key가 생성된 후에, 그것은 key path를 사용하는 value에 저장될 수 있거나 key로서 사용될 수 있다.
-
out-of-line key
-
저장되는 value와는 따로 저장되는 key.
-
key path
-
object store 또는 index에서 브라우저가 어디로부터 key를 추출해야 하는지 정의한다. 하나의 valid key path는 다음 중 하나를 포함할 수 있다: an empty string, a JavaScript identifier, or multiple JavaScript identifiers separated by periods. 그것은 spaces를 포함할 수 없다.
-
value
-
-

각각의 record는 하나의 value를 가진다, 이는 javascript로 표현될 수 있는 어떤 것이라도 포함할 수 있다, boolean, number, string, date, object, array, regexp, undefined, 그리고 null을 포함해서.

- -

object 또는 array가 저장될 때, 그 object 또는 array의  properties 와 values는 적합한 어떤 값이라도 될 수 있다.

- -

Blobs와 files가 저장될 수 있다, cf. specification.

-
-
- -

Range and scope

- -
-
scope
-
한 transaction이 적용되는 object stores와 indexe. read-only transactions의 scope은 겹칠 수 있고 동시에 실행될 수 있다. 한편으로, writing transactions의 scope은 겹칠 수 없다. 당신은 여전히 동시에 같은 scope의 여러 transaction을 실행할 수 있지만 그들은 queue up하고 하나하나 차례로 실행된다.
-
cursor
-
한 key range의 여러 records에 대한 iterating을 위한 mechanism. The cursor는 그것이 iterating하는 것이 어느 index또는 object store인지 가리키는 한 source를 가진다. 그것은 그 range 내의 position을 가지고, record keys의 순서에서 증가 혹은 감소하는 한 방향으로 움직인다. cursors에 대한 reference documentation을 위해, IDBCursor 또는 IDBCursorSync를 보라.
-
key range
-
-

keys를 위해 사용되는 몇몇 data type에 대한 하나의 연속 구간. Records는 keys 또는 하나의 range of keys를 사용하는 object sotres와 indexes로부터 조회될 수 있다. 당신은 lower 그리고 upper bound를 사용해서 range를 제한하거나 걸러낼 수 있다. 예를 들어, 당신은 x와 y 사이의 한 key의 모든 값에 대해 iterate할 수 있다.

- -

key range에 대한 reference documentation을 위해, IDBKeyRange를 보라.

-
-
- -

한계점들

- -

IndexedDB는 client-side storage가 필요한 대부분의 경우를 해결하기 위해 만들어졌다. 하지만 그것은 다음과 같은 몇 가지 경우를 해결하진 못 한다:

- - - -

덧붙여서, 다음과 같은 조건에서 브라우저가 데이터베이스를 지울 수 있음을 알아두라:

- - - -

정확한 삭제 시점과 브라우져의 DB 수용능력은 때때로 달라질 수 있습니다만, 브라우져 벤더가 지킬려고 노력하는 가장 기본적인 철학은 데이터를 가능한 최대한 데이터를 지킬려고 노력한다는 것입니다.

- -

Next steps

- -

이제 큰 그림은 이해할 수 있게 됐고 아울러 보다 복잡한 사용법을 익힐 준비가 됐네요. 실제로 어떻게 API를 사용하는지 알아보기 위해서, Using IndexedDB를 살펴봅시다.

- -

함께 보기

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