Web SQL 데이터베이스가 더 이상 사용되지 않는 이유는 무엇입니까?

하이브리드 Android 앱을 만들고 있습니다.

처음에 localStorage를 사용하기로 결정했습니다 .2 일을 보낸 후에는 그것이 매우 이상하다는 것을 깨달았습니다.

그런 다음 오늘 하루 종일 보내고 실제로 Chrome으로 출력을 얻은 후 indexedDB를 선택했는데 Android 앱의 WebView 내에서 실행되지 않습니다.

그리고 더 이상 사용되지 않기 때문에 Web SQL 데이터베이스를 전혀 사용하지 않았습니다. 어쨌든 PhoneGap은 여전히 Web SQL을 사용하고 안드로이드 브라우저는 그것을 지원한다는 사실을 알게되었습니다.

왜 Web SQL이 더 이상 사용되지 않습니까? 그리고 지금 Web SQL을 사용하는 것이 좋은 생각입니까?

— 모기
소스

localStorage에서 무엇을 발견 했습니까? 키 / 값 쌍 저장소 일뿐입니다. 나는 당신이 그것에 대해 싫어했던 것과 당신이 겪었던 문제의 유형에 대해 궁금합니다. 프로젝트에서 사용하고 있으며 발생한 사례 문제를 알고 싶습니다.

— jmq 2016 년

@oligofren, 만약 당신이 웹 SQL에서 단지 더 많은-죽은-간단한 SQL을 사용한다면, 당신은 정확하게 localStorage 등으로 번역 할 수 없습니다.

— Pacerier

그러나 추상화 계층을 만드는 번거 로움을 피하고 (dev-yathit.com/ydn-db/index.html) YDN-DB를 사용 하십시오 . 해당 장치에 가장 적합한 기술을 사용합니다.

— oligofren

항상 일종의 추상화 계층을 사용하고 있습니다. 그것은 프로그래밍이며 브라우저의 구현 버그에 관계없이 일관된 동작을 얻는 방법입니다. 더미 js 호출은 ms 당 5000을 초과하므로 YDN-DB 작성자가 어리석은 짓을하지 않는 한 100ms 정도의 성능에 영향을 미치지 않아야합니다. IndexedDB를 기본적으로 지원하지 않는 플랫폼에서 1ms와 비슷합니다. 현재는 이전 버전입니다. 현재 모든 브라우저는 IndexedDB를 지원합니다. WebSQL은 더 이상 사용되지 않습니다. 멀리 기술 :-)를 "최적화"전에 그리고 몇 가지 간단한 프로파일 링을 시도

— oligofren

@oligofren, 당신은 내 의견의 요점을 놓치고 있습니다. 나는 한 함수가 다른 함수를 호출하고 그 반대의 오버 헤드에 대해 이야기하지 않습니다. DB 추상화 계층을 사용할 때 성능 저하없이 사용할 수있는 SQL 쿼리 패턴 의 하위 집합으로 제한한다고 말하고 있습니다. 라이브러리가 자동으로 수행하므로 항상 올바르게 조정할 수는 없으므로 튜닝을 수행 할 수 없습니다. 한 행의 데이터 만 저장하지 않으면 1ms가되지 않습니다.

— Pacerier

답변:

짧은 버전 : 표준이 정말로 중요하고 Web SQL을 적절한 표준으로 전환하는 것은 엄청나게 어려웠 기 때문에 Web SQL은 더 이상 사용되지 않습니다.

Web SQL의 기존 구현은 기본적으로 SQLite를 감싸는 래퍼이므로 표준을 정의하려는 모든 시도는 기본적으로 "SQLite가 수행하는 작업"이었습니다. 이것은 충분하지 않습니다. 기존 구현 (특히 SQLite와 같은 타사 구현)을 가리 키지 않고 인터페이스와 코너 사례 및 예외 자체를 정의하려면 진정한 표준이 자체 포함되어야합니다. 그렇지 않으면 특정 구현의 단점을 취하고이를 표준으로 삼을 위험이 있습니다. 내가 읽은 바에 따르면 W3C는 제안 된 표준을 여러 번 독립적으로 구현하여 이러한 일이 발생하도록합니다. Web SQL은 SQLite에 너무 묶여 있었기 때문에 일어나지 않았습니다.

Mozilla의 블로그 는 특히 Web SQL을 지원하지 않는 이유에 대한 자세한 정보를 제공합니다. 분명히 그들은 Web SQL을 더 이상 사용하지 않는 주요 목소리 중 하나였습니다.

이제 Web SQL을 사용해야합니까? 현재 Google 및 Apple과 같이 현재 지원하는 공급 업체가 곧 떨어질 것으로 기대하지는 않지만 IE와 Firefox는 추가하지 않을 것이며 더 이상 사용되지 않으므로 왜 투자해야합니까? 예를 들어 Ido Green 은 Google Developer Relations과 함께 사용하지 않는 것이 좋습니다.

— 조쉬 켈리
소스

Ido의 게시물은 매우 기본적이며 왜 하나를 사용 해야하는지에 대한 표면을 긁지 않습니다. 실제로 noSQL 데이터베이스는 큰 크기를 염두에두고 설계되었으며 사용자의 단일 컴퓨터에서 실행되는 데이터베이스에는 적용되지 않습니다. 빅 데이터와 관련된 몇 가지 장점이 있지만 JOIN과 같은 항목은 손실됩니다. indexedDb를 사용해야하고 appengine에서 noSQL 데이터 저장소를 사용하는 경우 오픈 소스 "Plus for Trello"크롬 확장 프로그램을 개발할 수있는 방법이 없으므로 웹 SQL을 사용했습니다.

— Zig Mandel

Google GMail MS-Outlook 경쟁 업체는 전체 텍스트 검색을 수행 할 수 있기 때문에 SQLite 구현 (MS)이 하나 뿐이고 Jonas Sicking (Mozilla)이 SQL을 좋아하지 않기 때문에 "포괄, 확장, 소멸"을 수행 할 수 없기 때문입니다. 인터페이스가 지나치게 복잡한 주요 가치 저장소는 물론 모든 JavaScript 객체가 이미 연관 배열이기 때문에 훨씬 더 좋습니다 (일명 찬성). 그리고 데이터 정규화, 참조 무결성 및 집합 기반 작업은 SQL을 이해하지 못하는 사용자 ( "사용자는 SQL을 원하지 않음")에게 반란을 불러 일으 킵니다.

— Quandary

아이러니하게도 WebSQL은 SQLite와 정확히 상호 작용하기에 적합하며 PRAGMA가 필요하지 않습니다.

— Michael

그래서 mozilla는 일부 사람들이 좋아하지 않아 사람들을 방어하기 때문에 많은 상황에서 매우 유용한 프로젝트와 기술을 죽였습니다. 왜? 그들은 IndexedDB와 WebSQL을 모두 구현할 수있었습니다

— yoyo_fun

Safari 13은 이제 이전 버전의 WebSQL 에 대한 지원을 제거했습니다 .

— Thunderforge

조쉬 켈리 (Josh Kelley)의 답변은 지금까지 표준 작업이 중단 된 이유에 대해 내가 찾은 최고의 답변입니다. 즉, 사용자 기반과 관련하여 고려해야 할 추가 관점이 있다고 생각합니다.

이벤트에 대해 Ido Green의 접근 방식에 동의하지 않습니다 ( "웹 개발자가 더 이상 기술을 효과적으로 사용하지 않는 것이 좋습니다").

나는 (Ido Green의 기사에 대한 의견에서 vi4m 상태) :

우리 (개발자)는 여전히이 기술을 사용할 수 있습니다. 어떤 브라우저 벤더도이 기술의 제거를 요청하거나 제거 할 계획이 없습니다. 개발자는 웹의 목소리입니다. 우리는 여전히 그것을 사용할 수 있습니다. 어쩌면 Mozilla가 마음을 바꿀 것입니다 ;-)

그리고 또 다른 논리적 접근 방식을 추가하겠습니다. 모바일 환경을 위해 개발하는 경우 ... ¿ 어떤 주변 환경이 더 많은가? 답변 : iOS 및 Android ... 둘 다 webSQL을 지원하고 대상이 MASSIVE MOBILE 인 경우 가십시오!

큰 앱이 시작부터 거의 항상 해냈다 고 생각하고 MOST를 먼저 얻은 다음 (성공한 후에는) 나머지 부분을 줄이려면 작업을 다시 만드십시오 (실제로 달성하거나 요청하는 경우). 마지막으로 항상 성공을 거두는 사람은 없습니까?

놀란 로손의 기사를 읽은 후 (그의 발명에 대한 기회를 주려는 의도가 분명하다) 나는이 문제가 존재하지 않아야 할 기술 거인들 사이의 새로운 냉전이되었다고 믿는다. 나는 스펙이 계속 유지 될 것이라고 믿는다 (가능한 한 더 길고 손대지 않으면 서 클라이언트 지향 성능에 더 좋다). 아이러니하게도 "specs guys"작업은 새로운 스펙을 생성하는 것 (때로는 필요하지 않은 일이 있기 때문에 더 많은 것을 할 수있는 일)과 마찬가지로 프로그래머 작업은 때때로 새로운 문제에 대한 솔루션을 수행하는 대신 이미 작동하는 것을 변경하고 다시 작성하는 데 집중합니다. 그리고 새로운 경향.

클라이언트 측 데이터베이스는 단순히 서버와 클라이언트 측간에 병렬 처리를 수행하여 데이터를 쉽게 생성, 저장, 업로드 및 다운로드 할 수있는 문제였습니다. 이러한 접근 방식에서 동일한 언어와 구조 (적어도 LAMP 오픈 소스 개발자)는 논리적이고 직설적입니다.

더 넓고 새로운 가능성을 가진 대안이 되려는 IndexedDB의 의도는 항상 좋은 접근 방법이라고 생각하지만 NEEDS를 설치할 소프트웨어를 개발해야 할 필요가 있습니다 (핵심 솔루션이 클라우드에 머무를 수있는 경우에도). 연결 상태를 유지하는 경향이있는 세상에서는 A) 통제와 소유의 문제 또는 B) 클라이언트 쪽의 괴물을 개발하는 데 중점을 둔 것처럼 들리지만 이러한 종류의 요구에는 앱 (모바일 세계)과 소프트웨어가 있습니다. (PC 세계에서). Webapps의 목표는 주로 장치에 관계없이 웹을 확장하는 데 머물러 있어야한다고 생각합니다.

나는이 접근법에서 좋은 인포 그래픽이 나올 수 있다고 믿는다.

— DavidTaubmann
소스

최신 Firefox 버전과 IE는 WebSQL을 전혀 지원하지 않습니다.

— ocodo

내가 아는 한, 그들은 WebSQL을 지원하지 않았습니다. [link] caniuse.com/#feat=sql-storage 에서 확인할 수 있습니다 . 나를 놀라게하는 유일한 것은 Opera Mini입니다. 그들은 이런 식으로 시장을 잃어 가고 있습니다. 어쨌든, 개발자로서 중요한 것은 iOS 및 Android for WebApps뿐 아니라 WebKit도 모두 시스템 엔진이라고 생각합니다.

— DavidTaubmann

그럼에도 불구하고, 어떤 클라이언트 측 스토리지 표준은 모두 상용 브라우저에 의해 채택되지 않은 : html5rocks.com/en/features/storage

— DavidTaubmann

Safari 13은 이제 이전 버전의 WebSQL 에 대한 지원을 제거했습니다 . 따라서 "브라우저 공급 업체가이 기술의 제거를 요청하지 않았거나 제거 할 계획도 없습니다"는 더 이상 사실이 아닙니다.

— Thunderforge

@Thunderforge 정보를 주셔서 감사합니다! 정말 반가워요! 조금 생각하면,이 도구가 수년 동안 우리에게 완벽하고 유용했기 때문에 iOS에 더 나쁜 개발자에게 나쁜지 모르겠습니다. 누군가가 프로젝트를 indexedDB에 다시 프로그래밍하는 데 드는 비용을 지불하지 않는 한, 사용자는 더 이상 Mac 또는 iOS 장치를 사용하거나 구매하지 않는 것이 좋습니다.

— DavidTaubmann

실제로 기여하는 당사자는 표준의 방향에 대한 어려움에 도달했습니다. 요컨대, 아무도 동의 할 수 없었습니다.

W3C 사이트에서이를 설명합니다.

사양은 난관에 도달했습니다. 관심있는 모든 구현자가 동일한 SQL 백엔드 (Sqlite)를 사용했지만 표준화 경로를 진행하려면 여러 개의 독립적 인 구현이 필요합니다.

WSC 사이트

— htm11h
소스

나에게 이것은 어쨌든 그들이 그 길에서 표준화 할 다른 것이 없다는 데 동의한다는 것을 의미합니다 ... 표준의 경로를 표준화하지 말아야 할 기존의 타사 기술에 연결하기 때문에 표준 경로를 잘 작동합니다.

— DavidTaubmann

나에게 그 소리는 다음과 같습니다 : 그들은 공급 업체별 기능 (허용, 확장, 소멸?)을 허용하지 않기 때문에 동의하지 않았습니다.

— Quandary

나는 그것이 일종의 벤더 특유의 선호라고 믿고, 다음 문장은 연구가 계속되고 있다고 말합니다. 따라서 모든 당사자가 현재 상태에 만족하는지 확신 할 수 없습니다 ... "웹 응용 프로그램 작업 그룹은 다른 두 가지 저장소 관련 사양 인 웹 저장소 및 인덱싱 된 데이터베이스 API에 대한 작업을 계속합니다."

— htm11h