Re: Web SQL Database 

안녕하세요. 조만영입니다.

조금 뜬금없는 말씀입니다만 박재성님 말씀에서 느껴지는 여러 아쉬움들을 읽으면서
그래서 국내기업들도 W3C 웹표준화 활동에 참여하는 것이 중요하다는 말씀을 드리고 싶습니다.
NHN 과 같은 회사 혹은 다른 국내 기업들이 WebSocket 논의를 계속 귀기울이고 있고
필요한 시점에 목소리를 낼 수 있었다면 이렇게 일방적으로 결정되고 통보 받는
상황을 아주 조금이라도 미리 변화시키고 또는 미리 준비를 할 수 있지 않을까
하는 생각이 듭니다.

W3C 웹표준화에 활동하는 것이 거창하게 외국기업들만이 하는 것이 아니며
논의된 내용이 우리의 웹 생태계에 바로 직결된다는 점에 대한 인식이 HTML5 대한민국 관심그룹
활동을 통해서 점점 확산되었으면 합니다.

감사합니다.


2010/12/9 박재성 <jaesung.park@nhn.com>

> 안녕하세요. 박재성 입니다.
>
>
> 역시 고수분들의 의견을 들으니 좀더 깊게 이해되는 부분들이 있어서 좋네요.
>
>
> 그냥 간단히 제 의견을 말씀드리자면, 이제 지원하는 브라우저 들도 늘고 있고,  어느 정도 구현 자체가
>
> 실 서비스에서 사용하기에 무리 없다고 생각되던 시점에 이제 표준대상에서 제외된다...라고 하니
>
> 당황스러운 부분이 있다는 것이죠.
>
>
> 모든 결정에는 "그냥 결정이 되었다"는 없고, 당연히 그러한 결정이 내려지기 위해 수많은 논의가 오갔을 테지만
>
> 그 과정을 일반 사용자 입장에서 들여다 보기는 쉽지 않거든요.
>
>
> 물론 SQLite가 태생적인 한계로 인해 부족한 것이 사실이고  타 DB data 수용문제가 있다고 하지만, 어차피
>
> 기존 RDBMS인 오라클이나 DB2나 등등.. 들도 마찬가지로 벤더 들에 따라 데이터 타입이나 함수, 등이 조금씩
>
> 달라서 서로간의 마이그레이션 작업도 그리 만만한 것은 아닙니다.
>
>
> 결국 사용자가 어떤 것을 사용하느냐를 결정하면 되는 것이라고 생각됩니다.
>
>
> 따라서 수년간 발전/구현 되어 온 것을 굳이 제외할 필요없이 Web Storage의 한 부분으로 가져가도 되지 않을까
>
> 라는 생각을 얘기하고 싶었던 것이죠.
>
>
> 기존의 사례를 봐도 IE에서 표준이 아닌 자신들만의 API를 만들었지만, 결국 많은 사람들이 사용하게 되고 니즈가
>
> 증가하면서 결국 다른 벤더들도 지원하는 형태... 그리고 결국 그게 표준에 포함되었던 것처럼 표준은 보다 큰
>
> 범위내에서 고려가 되어야 하겠지만, 니즈(얼마나 많은진 모르겠지만...)도 같이 고려되었어야 하지 않았나 하는
>
> 아쉬움이 남네요.
>
>
> 실제 관련 기술들을 이용해서 무엇인가를 구현하는 입장에서는 구현하는 것이 더 늦어지게 됐다는 것이 핵심일 듯 하네요.
>
>
> 고맙습니다.
>
>
>
>
> -----Original Message-----
> *From:* "이원석"
> *To:* channy@gmail.com
> *Cc:* "박재성"; public-html-ig-ko@w3.org
> *Sent:* 10-12-09(목) 08:32:55
> *Subject:* RE: Web SQL Database 관련
>
>  안녕하세요. 윤석찬 팀장님.
>
> 친절한 답변 감사합니다~
>
> 아래와 같이 저의 의견을 적어봤습니다~ ;)
>
>
>
> *From:* Channy Yun [mailto:channy@gmail.com]
> *Sent:* Thursday, December 09, 2010 2:53 AM
> *To:* 이원석
> *Cc:* 박재성; public-html-ig-ko@w3.org
> *Subject:* Re: Web SQL Database 관련
>
>
>
> 더 길어질 필요는 없겠지만 몇 가지만 답변을 드리면요.
>
> è    *여러가지 의견을 공유하는 것이 우라 KIG의 중요한 목적중의 하나입니다^^*
>
> è    *다른 분들도 편하게 의견주세요~ ;)*
>
> 1. Vlad의 글에서 Web Storage는 http://dev.w3.org/html5/webstorage/ 이구요. 과거 DOM
> Stroage라고
>    부르는  sessionStroage와 localStorage입니다. 첫 문장에 링크가 문서에 있습니다. Web Storage나
>     WebSQLDatabase가 sqlite를 쓰고 있는 아이러니한 현실을 지적한 것입니다.
>
> *-**à* *그러네요^^;; 이건 제가 착각을 하고 있었네요~*
>
> *à* *내용이 주로 SQL 문제와 DB 문제를 이야기 하고 있어서요. 그랬나 봅니다… ;)*
>
>
> 2. Web SQL Database가 왜 SQLite를 기반으로 만들어진거죠? SQL문이 SQLite에 종속적인건 이해가 가지만
>     그 API들은 일반적인 DB 처리 인터페이스와 그리 다르지 않습니다. connect, selectdb, query,
> fetch, close
>     이게 다 인데 그냥 rdb 라이브러리지 sqlite 종속적인건 아닙니다.
>
>  è    *예. API 부분은 문제가 없습니다~ SQL문이 문제가 되는 것이죠.*
>
>
> 3. 이런저런 말이 많지만 결론적으로 SQL 구현체를 제공하는 현재 방식 보다 Key/value 기반 저장소를 제공하자는
>    결론입니다. 그렇게 되면 구현의 정도에 따라 조금의 차이가 있지만 결과적으로 Web Storage와 IndexedDB의
>    구현물은 결국 같습니다.
>
> è    *약간 오해가 있을 것 같아서 다시 한번 말씀드리면,*
>
> è    *브라우저에서 Web Storage와 IndexedDB의 엔진이 같은지 다른지는 별로 중요한 것이 아니라고 생각됩니다.*
>
> è   *어떤 API가 제공이 되는지가 중요합니다.*
>
> è   *예를들어 Web Storage에서 충분한 API가 제공되었다면 DOM Storage Query Language 같이 별도의
> 솔류션들이 나올 필요가 없을 겁니다.*
>
> è  *이미 SQLite에 이런 기능이 있지만 Web Storage에서 원하는 API를 제공해 주지 않기 때문에 어떻게 보면 중복이
> 되는 기능을 js로 또 만들게 되는 것입니다.*
>
>
>
> 4. 실제 현실에서 IndexedDB에다가 수십만행의 데이터를 넣고 처리해야 하는 유즈케이스는 없는데
>     결국 처음 박재성님의 질문대로 WebSQL Database를 쓸 것이냐 IndexedDB가 나올때 까지 기다리겠냐에서
>     WebStorage를 써라는 가장 현실적인 답을 한 것입니다.
>
>  è    *말씀하신데로 IndexedDB가 없는 상황에서 Web Storage를 일단 사용하는 것은 동의합니다~ 다른 대안이
> 없으니까요.*
>
> è    *하지만 Web Storage의 구현체가 SQLite이더라도 Web Storage의 간단한 API만을 가지고는 웹앱을
> 만드는데 한계가 있을 수밖에 없습니다.*
>
>
> 우리가 당장 구현을 하는 입장에서 표준의 목적에 따라 쓰고 안쓰고를 고민할 만큼 한가하지 않다고 생각되거든요.
> 그리고 모바일 웹에서 현재 사용하는 유즈케이스만큼의 데이터를 WebStroage에 넣어 처리했다고 해서 그게 목적을
> 위배한다고 보여지지도 않습니다.
>
> 저도 표준의 목적에 대해서는 이의가 있는 건 아닙니다만 그 범위를 함부로 정하지는 말아야 한다고 생각하네요.
>
>  è    *이 부분의 의견은 정답이 있는 부분이 아니니 간단하게만 의견을 말씀드리면,*
>
> è    *제가 활용 범위를 제한한 적은 없는 것 같은데요~ 물론 제가 한정한다고 한정되는 것도 아니구요~ ;)*
>
> è    *표준을 활용하는 것은 개발자 마음입니다. 하지만 가능하면 목적에 맞게 사용하는 것이 좋을 것이라 생각됩니다^^*
>
>
>
>
>
> 이원석 드림.
>
>
>
> Channy
> ---------------------
> http://www.linkedin.com/in/channy
>
> * Biomedical Knowledge Engineering Laboratory http://bike.snu.ac.kr
> * Daum Developers Network & Affiliates http://dna.daum.net
>
>
>  2010/12/9 이원석 <wslee@etri.re.kr>
>
> 안녕하세요. 윤석찬 팀장님.
>
> 좋은 의견 감사합니다~
>
>
>
> 보내주신 의견에 아래와 같이 inline 코멘트를 달았습니다~ ;)
>
>
>
>
>
> *From:* Channy Yun [mailto:channy@gmail.com]
> *Sent:* Thursday, December 09, 2010 12:21 AM
> *To:* 이원석
> *Cc:* 박재성; public-html-ig-ko@w3.org
> *Subject:* Re: Web SQL Database 관련
>
>
>
> 이원석님 말씀은 대부분 맞는 말이지만, 좀 더 깊은 이해가 필요 합니다. (이미 이런 토론은 많았지만요.)
>
> 우선 현재 많은 브라우저가 SQLite를 탑재하고 있고, DOM Storage(지금은 Web Storage) 역시 SQLite에
> 저장되고 있습니다. Key/Value 저장 형식인데도 실제 구현은 브라우저에서 SQLite로 저장하고 있죠.
> WebSQL Database는 바로 SQLite에 저장하는 것이구요. 만약 SQLite가 아닌 mySQL로 바꾼다고
> 생각해 보세요. 브라우저 밑단을 다 바꾸어야 하는 일이 생깁니다. (웹 개발자가 아니라 브라우저 개발자를
> 말하는 것입니다.)
>
> 따라서 IndexedDB로 가는 가장 큰 이유가 바로 Key/Value 형식이 B-tree 기반의 저장소가 낫다고
> 판단을 하는 것이고 relation이나 대용량 데이터를 다루지 않는 프론트웹의 형식에 가장 적합하고
> 경우에 따라 MapReduce 기반이나 CouchDB 같은 noSQL을 선택하는 옵션이 가능하다는 점입니다.
> (사실 프론트 엔드에 rdb가 있다고 서버의 모든 사용자 데이터를 싱크할 건 아니잖아요 ㅎㅎ)
>
> 결론적으로 브라우저는 저장소를 제공하는 것이지 원한다면 웹 개발자가 sql 구현체를 만들어 쓰라는 것입니다.
>
> è    *먼저 적어주신 내용을 제가 잘 이해했는지는 모르겠지만 아래와 같이 제 의견을 드릴 수 있을 것 같습니다.*
>
> è    *아래에 문서로 적어주신
> http://blog.vlad1.com/2009/04/06/html5-web-storage-and-sql/ 를 보니 죄송하지만
> 석찬님께서 조금 잘못 이해를 하고 계시지 않나 생각이 드네요.*
>
> è    *(**참고로 이 문서에서 web storage는 DB 기능을 의미하는 것입니다^^ 이게 일반적인 용어라 이런 문제가 있네요
> ^^)*
>
> è    *위에서 말씀하신 SQLite를 mySQL로 바꾸는 경우의 문제는 DOM Storage 기능과 Web SQL Database기능이
> SQLite를 기반으로 구현이 되어 있기 때문이 아닙니다.*
>
> è    *왜냐하면 이건 표준의 문제가 아니며, 개발에 대한 이슈입니다. 즉, 플랫폼 개발사의 선택의 문제이기 때문이며, 개발사의
> 전략에 따라 언제든 좋은 방법으로 다시 구현하면 됩니다.*
>
> è    *이것 때문에 IndexedDB 표준이 대체표준으로 개발이 되고 있다고 이야기 하는 것은 무리가 있어 보입니다.*
>
> è    * *
>
> è    *말씀하신 http://blog.vlad1.com/2009/04/06/html5-web-storage-and-sql/ 문서에
> 보면 Web SQL Database가 왜 상호운용성 문제가 있는지에 대한 이유가 잘 설명이 되어 있습니다.*
>
> è    *SQLite**을 사용하면서 발생되는 근본적인 문제는 SQLite의 SQL 변형이라는 것입니다.*
>
> è    *즉, SQLite에서 사용하는 SQL이 다른 SQL 엔진들과 편차가 크며, 이러한 문제의 가장 큰 원인은 컬럼에 대한
> 데이터 타입 부분의 편차 때문이라는 것입니다.*
>
> è    *DB**의 컬럼에 대한 데이터 타입에 편차가 있다면 당연히 당연히 다른 데이터베이스와는 상호운용성 보장에 문제가 있겠죠.*
>
> è    *따라서 SQLite를 기반으로 만들어진 기존의 Web SQL Database 스펙이 문제가 된다는 것입니다. 왜냐하면
> 기존의 DB를 모두 SQLite의 SQL에 맞추어 수정을 해야하니까요.*
>
> è    *그럼 왜 SQLite가 이러한 문제를 갖을까요? 근본적으로 SQLite의 태생에 있습니다. SQLite는 임베디드 시스템을
> 위해 개발된 데이터베이스이기 때문입니다.*
>
> è    *결과적으로 이러한 상호운용성 문제 때문에 SQL을 사용하는 것보다 낮은 레벨의 IndexedDB API 표준을 개발하고
> 있는 것입니다.*
>
>
> 참고.
> http://blog.vlad1.com/2009/04/06/html5-web-storage-and-sql/
> http://hacks.mozilla.org/category/indexeddb/
>
>
> 어쨌든 SQL 보다 한 단계 낮은 구현체는 브라우저 벤더들의 현실적인 문제에 의한 것이죠. 하지만, 논의만
> 많이 했지 실제로 구현 속도는 매우 느릴 것으로 예상합니다.
>
> 우선 websql db/indexed db를 안(못)쓰고 key/value 저장 형식을 쓰는 게 좋고 그런 측면에서 web
> storage는
> 현실적 대안이 됩니다. 원석님께서 web storage가 대량 데이터를 저장하는 것이 적합하지 않다고 하셨는데
> 구현 측면에서 web sql database와 비교해서 어떤점이 적합하지 않은지 잘 모르겠습니다.
>
> web storage는 cookie를 대체하라고 있는 게 아닙니다. 모바일 웹에서 dom에서 빠르게 핸들링할 수 있는
> 최소 수준 이상의 데이터를 다루라고 있는 것입니다.
>
> 지금은 어차피 db(sqlite)에 담는 것이구요. 예를 들어, websql db를 쓰는 모바일 지메일의 경우 테이블이
> top query와 본문내용을 담은 테이블 2개 정도가 주 데이터이고 담아 놓는 메일량도 최신 메일만 보는
> 서비스적 습성 때문에 20~40개만  인덱싱을 합니다. (그림 참고 http://twitpic.com/3e2uco )
>
> 결론적으로 web storage를 가지고 sql 구현체를 만든 아래 js 라이브러리를 보시면 제가 한 말을 이해하실 수
> 있을 것이라 생각합니다.
>
> http://code.google.com/p/dom-storage-query-language/
>
>  è  *DOM Storage Query Language* *같은 좋은 approach를 말씀해 주셔서 감사합니다^^*
>
> è  *그리고 Web SQL Database와 IndexedDB를 못쓰는 상황에서 Web Storage(여기서는 SessionStorage
> + LocalStorage를 의미^^)를 사용하고,*
>
> è  *여기에 DOM Storage Query Language와 같은 Approach로 Web Storage를 DB와 유사하게
> 활용하는 방식에 대해는 괜찮다고 생각을 합니다.*
>
> è  *이건 어떤 타겟이 되는 웹앱의 요구사항에 따라서 좋은 솔류션이 될 수 있다고 생각이 듭니다.*
>
> è  *물론 IndexedDB API를 브라우저들이 제공을 하게되면 어떤 방식이 좋은지 다시 비교가 필요할 것이라고 생각됩니다.*
>
> * *
>
> è  *그런데 저의 전 메일에 대해서 약간의 오해가 있으신 것 같습니다.*
>
> è  *제가 지난 메일에서 말씀드리고 싶었던 포인트는 현재 개발되고 있는 Web Storage와 IndexedDB 표준에 대한 각각의
> 목적입니다.*
>
> è  *어떤 목적으로 이런 표준들이 개발되고 있는지에 대한 부분입니다.*
>
> è  *말씀하신데로 Web Storage를 기반으로 DOM Storage Query Language라는 js 프로그램이 나와서 DB같은 기능을 할 수 있을지는 모르지만
> *
>
> è  *이건 Web Storage 표준의 근본적인 목적은 아니라는 것입니다.*
>
> è  *대량의 데이터를 처리하기 위한 DB 기능을 제공하기 위해 개발 중인 표준은 IndexedDB이며, 따라서 Web Storage
> + DOM Storage Query Language로 DB 기능을*
>
> è  *만들 수는 있지만 극히 일부기능이 될 것이며, 성능면에서 IndexedDB를 사용하는 것보다 느릴 것입니다. 또한 Key 값
> 기준의 순차적인 검색 기능 등 다양한 기능을 js 스크립트로 추가하는 것도 쉽지 않을 것이라 생각이 됩니다.*
>
> è  *참고로 http://www.w3.org/TR/IndexedDB/ 문서의 소개 부분을 보세요. 아래와 같은 문장이 있습니다.*
>
> è User agents need to store large numbers of objects locally in order to
> satisfy off-line data requirements of Web applications. [WEBSTORAGE<http://www.w3.org/TR/IndexedDB/#bib-WEBSTORAGE>]
> is useful for storing pairs of keys and their corresponding values. However,
> it does not provide in-order retrieval of keys, efficient searching over
> values, or storage of duplicate values for a key.
>
> è This specification provides a concrete API to perform advanced key-value
> data management that is at the heart of most sophisticated query processors.
> It does so by using transactional databases to store keys and their
> corresponding values (one or more per key), and providing a means of
> traversing keys in a deterministic order. This is often implemented through
> the use of persistent B-tree data structures that are considered efficient
> for insertion and deletion as well as in-order traversal of very large
> numbers of data records.
>
> * *
>
> * *
>
> *이원석 드림*
>
>
> Channy
> ---------------------
> http://www.linkedin.com/in/channy
>
> * Biomedical Knowledge Engineering Laboratory http://bike.snu.ac.kr
> * Daum Developers Network & Affiliates http://dna.daum.net
>
> 2010/12/8 이원석 <wslee@etri.re.kr>
>
> 안녕하세요~ 박재성님.
> 좋은 질문 감사합니다~
>
> Web SQL Database는 현재 W3C Note Track으로 가는 것에 MS를 비롯해서 모든 기업들이 동의를 하고 있습니다.
> 그리고 HTML5 에디터인 구글의 Ian Hickson은 WHATWG의 HTML5 문서에서 이에 대한 부분을 이미 제거를 했다고
> 이야기를 하구요..
> 개발자 입장에서는 좀 아쉽겠지만 어쩔 수 없는 것 같습니다~
>
> 그리고 Web SQL Database가 표준에서 하차를 하게된 이유는 회의때 말씀을 간단하게 드렸었지만,
> 일단 현재 브라우저들이 모두 SQLite를 내장을 하고 있고 여기서 지원하는 SQL를 표준으로 사용할 수 없기 때문입니다.
> 또한 SQL이 ISO 표준이 존재하기는 하지만 각 DB만다 다양한 SQL 문을 지원을 하기 때문에 서로 합의할 수 있는 접점을 찾는
> 것이 힘든 것이 사실입니다.
>
> 하지만 이러한 DB 기능은 웹앱에서도 상당히 중요합니다. 그래서 SQL 레벨보다 한단계 낮은 단계의 API를 Indexed
> Database API라는 표준으로 개발하고 있습니다.
> 먼저 이러한 기능은 HTML5의 Offline Web Application을 지원하기 위해서는 반드시 필요하죠.
> 예를 들어 email 웹앱의 경우 통신이 안되는 상황에서도 웹앱을 정상적으로 실행하기 위해서는
> 웹앱자체의 캐슁도 필요하지만 일부 메일 데이터 자체도 캐슁을 해야합니다.
> 이럴 때 DB기능은 필수적으로 필요합니다. 이런 경우 Web Storage를 사용하는 것은 적합하지 않습니다.
> 즉, Web Storage는 간단한 정보를 저장하기 위한 목적이라면, DB기능은 대량의 데이터 관리를 위한 목적입니다.
> 또한 Web Storage는 키 기반 순차적으로 검색 기능 등 대량의 데이터 관리를 위한 기능을 지원하지 못합니다.
>
> 저는 향후 어떻게 될지는 모르겠지만 일단 SQL 레벨보다 한단계 낮은 단계의 Database API를 지원하는 것은 그나마 다행이라고
> 생각합니다~ ;)
> 그리고 향후에 이러한 기능 위에 좀더 편리한 기능을 지원하는 추가적인 표준 개발도 가능할 수 있을 것을 봅니다~ ;) 물론 현재까지는
> 바램이지죠~ ;)
>
> 차기 회의때 Web SQL Database와 Indexed Database에 대한 좀더 구체적인 소개를 하는 자리를 갖으면 좋을 것
> 같습니다.
> 혹시 발표해주실 분이 계신가요?? Volunteer를 찾습니다~ ;)
>
>
> 이원석 드림.
>
>
>
> > -----Original Message-----
> > From: public-html-ig-ko-request@w3.org [mailto:public-html-ig-ko-
> > request@w3.org] On Behalf Of 박재성
> > Sent: Tuesday, December 07, 2010 4:41 PM
> > To: public-html-ig-ko@w3.org
> > Subject: Web SQL Database 관련
> >
> > 안녕하세요. NHN의 박재성 입니다.<br><br>KIG 첫 메일을 다른 분들의 의견을
> > 구하는 내용으로 시작해 봅니다.<br><br>2차 모임때 이원석 박사님께서 언급해
> > 주시기도 했고, 이미 알고 있던 내용이었지만 Web SQL Database가 deprecated 되었다는 내
> > 용을 보고<br>조금은 실망(?)스러웠었는데요... (아마도 Indexed DB API가 대체되는
> > 형태이겠죠.)<br><br>W3C 내부적으로 논의가 있었겠지만, 이미 Web SQL
> > Database는 WebKit 계열의 브라우저에서 구현되어 있고, 몇년동안 계속 <br>사용이 되
> > 어왔었는데 굳이 대체할 필요가 있었을까란 생각이 듭니다.<br><br>그리고 아직
> > Indexed DB API를 구현한 브라우저도 현재까진 없는 상태이구요.<br>(Firefox 4에
> > 서 지원예정이고, 구글코드에 <a
> > href="http://code.google.com/p/indexeddb/&quot;&gt;http://code.google<http://code.google.com/p/indexeddb/%22%3Ehttp:/code.google>
> > .com/p/indexeddb/</a> 구현체가 있긴하지만 오랜시간 동안 구현되어왔던
> > <br>Web SQL DB와는 다르다고 생각됩니다.)<br><br>Web SQL
> > Database가 deprecated 된 이유 중 하나가 W3C에선 표준화를 위해선 여러 형태의 구현체가 필
> > 요한데,<br>현재 Web SQL Database 구현체가 대부분 SQLite로 단일화 되어 있는 형
> > 태이기 때문이란 의견도 있더군요.<br><br>HTML5 KIG 다른 분들의 생각은 어
> > 떠신지 궁금합니다.<br><br>고맙습니다.<br><br>
> > <br><br><br>
>
>
>
>
>



-- 
Manyoung Cho
===========
Web Evangelist | http://webdevmobile.com
Business and Technlogy Specialist | W3C Korea office

Blog : http://manyoung.net
Twitter : http://twitter.com/manyoungc
Linkedin : http://kr.linkedin.com/in/manyoung

Received on Thursday, 9 December 2010 03:20:08 UTC