Web SQLデータベースが非推奨になったのはなぜですか？

ハイブリッドAndroidアプリを作成しています。

最初にlocalStorageを使用することに決めました。2日間を費やした後、非常に奇妙であることに気づいたため、削除しました。

次に、indexedDBを選択しました。今日の1日を費やして実際にGoogle Chromeで出力を取得した後、AndroidアプリのWebView内で実行されていません。

また、Web SQLデータベースは廃止されたため、まったく使用しませんでした。とにかく、PhoneGapはまだWeb SQLを使用しており、Androidのブラウザーがそれをサポートしていることに気づきました。

そもそもWeb SQLが廃止されたのはなぜですか？また、今すぐWeb SQLを使用することをお勧めしますか？

— ぶよ
ソース

localStorageのどこがおかしいと感じましたか？これは単なるキー/値ペアストアです。私はあなたがそれについて気に入らなかったものとあなたが遭遇した問題のタイプに興味があります。私はプロジェクトでそれを使用していますが、あなたが遭遇したケースの問題を知りたいです。

— jmq 14年

@oligofren、もしあなたがweb SQLで単なる頭脳以上のシンプルなSQLを使っているなら、それをlocalStorageなどに正確に翻訳することはできません

— 。– Pacerier

ただし、抽象レイヤーを作成する手間を省き（これは私が行いました）、今はdev.yathit.com/ydn-db/index.htmlで YDN-DBを使用するだけです。そのデバイスに最適な技術を使用します。

— オリゴフレン

常に何らかの抽象化レイヤーを使用しています。それがプログラミングであり、ブラウザの実装バグに関係なく一貫した動作を実現する方法です。ダミーのjsコールは1ミリ秒あたり5000を超えるため、YDN-DBの作成者がばかげてばかげたことをしない限り、100ミリ秒程度のパフォーマンスのヒットはありません。IndexedDBをネイティブにサポートしないプラットフォームでの1対1の操作の場合の1msに近い。現時点では、これは古いバージョンのみです。現在のブラウザはすべてIndexedDBをサポートしています。WebSQLは非推奨です。あなたは離れてハイテク:-)を「最適化」の前といくつかの簡単なプロファイリングを試してみてください

— oligofren

@oligofren、あなたは私のコメントの要点を逃しています。私は、ある関数が別の関数を呼び出すオーバーヘッドと、その逆については話していません。db抽象化レイヤーを使用すると、パフォーマンスの低下を招くことなく使用できるSQLクエリパターンのサブセットに制限されることになります。ライブラリが自動的に調整を行い、常に正しく取得するとは限らないため、調整を行うことはできません。1行のデータのみを保存しない限り、1ミリ秒にはなりません。

— Pacerier

回答:

短いバージョン：Web SQLは非推奨になりました。標準が本当に重要であり、Web SQLを適切な標準に変えることは非常に困難だからです。

Web SQLの既存の実装は基本的にSQLiteのラッパーであるため、その標準を定義しようとする試みは基本的に「SQLiteの機能を実行する」ことでした。これは十分ではありません。既存の実装（特にSQLiteのようなサードパーティの実装）を指すのではなく、インターフェースとコーナーケースと例外自体を定義するために、真の標準が自己完結型である必要があります。そうしないと、ある特定の実装の癖を取り、それらを標準として安置するリスクがあります。私が読んだことから、W3Cは、これが確実に行われるようにするために、提案された標準の複数の独立した実装を好みます。Web SQLはSQLiteと非常に密接に結びついていたため、それは起こりませんでした。

Mozillaのブログでは、特にWeb SQLをサポートしていないという理由について詳しく説明しています。どうやら、Web SQLを非推奨にする主要な声の1つだったようです。

今すぐWeb SQLを使用する必要がありますか？GoogleやAppleなど、現在サポートしているベンダーがすぐにそれをドロップすることは期待していませんが、IEとFirefoxは追加しません。（たとえば、Google Developer RelationsのIdo Greenは、使用を推奨していません。）

— ジョシュ・ケリー
ソース

Idoによるこの投稿は非常に基本的なものであり、なぜどちらを使用する必要があるのかについても表面的には触れていません。実際、noSQLデータベースは大きなサイズを考慮して設計されており、ユーザーの単一のコンピューターで実行されているデータベースには適用されません。ビッグデータに関連するいくつかの利点を得ることができますが、JOINのようなものを失います。indexedDbを使用する必要がある場合（およびappengineでnoSQLデータストアを使用する場合）、オープンソースの "Plus for Trello" Chrome拡張機能を開発する方法はないため、Web SQLに進みました。

— ジグマンデル

これは、Google GMail MS-Outlookのライバルがフルテキスト検索を実行でき、SQLite実装（MS）が1つしかない場合は「包含、拡張、終了」が不可能であり、Jonas Sicking（Mozilla）はSQLを好まないためです。特にすべてのJavaScriptオブジェクトはすでに連想配列であるため、複雑すぎるインターフェイスを備えたキーバリューストアは、もちろんはるかに優れています（別名ハイフ）。それに直面してみましょう。データの正規化、参照整合性、およびセットベースの操作は、SQLを（wantTo）理解していない人（別名「ユーザーはSQLを望まない」）にとって不快です。

— 苦境

皮肉なことに、WebSQLは、SQLiteとやり取りするのに最適です（PRAGMAを必要としない場合）。

— マイケル

そのため、mozillaはプロジェクトを殺し、多くの状況で非常に有用なテクノロジーを使用しました。一部の人々はそれを好まないため、人々はそれらを擁護しました。どうして？彼らはのIndexedDBとWebSQL BOTH実装することができます

— yoyo_fun

Safari 13では、以前のバージョンにあったWebSQLのサポートが削除されました。

— サンダーフォージ

ジョシュ・ケリーの答えは、これまでのところ、標準的な仕事をやめる理由について私が見つけた最高の答えです。そうは言っても、ユーザーベースに関しては考慮すべき追加の視点があると思います。

Eventhough、私は主題に対するIdo Greenのアプローチに同意しません（「これは、Web開発者が技術を効果的に使用しないことを推奨します」）...

私は信じています（vi4mがIdo Greenの記事のコメントで述べているように）：

私たち（開発者）はまだこの技術を使用できます。この技術の削除を要求したブラウザベンダーも、削除する予定もありません。開発者はウェブの声です。まだ使用できますが、Mozillaは気が変わるかもしれません;-)

また、別の論理的なアプローチを追加します。モバイルアンビエント向けに開発している場合...¿ 回答：iOSおよびAndroid ...したがって、両方がwebSQLをサポートし、ターゲットがMASSIVE MOBILEである場合は、それを試してください！

大規模なアプリは最初からほぼ常に行われており、最初にMOSTを取得し、次に（成功した場合）作業を再作成して残りを減らします（本当に達成したい場合、またはそうするように求められた場合）。最後に、パスをマークするのは常に成功しているわけではありませんか？

ノーラン・ローソンの記事（彼の発明にチャンスを与えるという彼の意図は明らかです）を読んだ後、私はこの問題が、存在すらしてはならない技術巨人間の新しい冷戦になったと信じています。私は仕様が維持されるように作られていると信じています（可能な限り長く、手付かずのままであるほど、クライアント指向のパフォーマンスにとってはより良い）。皮肉なことに、「specs guys」の仕事は、新しい仕様を生成することです（必要がない場合もあるので、彼はもっと何かをすることができます）。そして新しい傾向。

私にとって、クライアント側データベースは、サーバー側とクライアント側の間で単純に並列化することで、データを簡単に作成、保存、アップロード、ダウンロードできました。このアプローチでは、同じ言語と構造（少なくとも私たちにとってはLAMPオープンソース開発者）を持つことは単純明快で論理的です。

IndexedDBがより広く、より新しい可能性を持つ選択肢になるという意図は常に良いアプローチであると信じていますが、何らかの形で、NEEDSをインストールするソフトウェアを開発する必要性に似ています（コアソリューションがクラウドに留まる場合でも）。接続されたままになる傾向のある世界では、A）制御と所有の問題、またはB）クライアント側のモンスターの開発に焦点を当てているように聞こえますが、そのようなニーズにはアプリ（モバイルの世界）とソフトウェアが存在します（PCの世界）。Webappsの目標は、デバイスに関係なく、主にWebを拡張することです。

このアプローチから素敵なインフォグラフィックが出てくると思います。

— デビッドタウブマン
ソース

Firefoxの最新バージョンとIEはWebSQLをまったくサポートしていないことに注意してください。

— オコド

私の知る限り、WebSQLをサポートしたことはありません。これは[link] caniuse.com/#feat=sql-storageで確認できます。私を驚かせるのはOpera Miniだけです。彼らはこのように市場を失いつつあります。とにかく、開発者としての私にとって重要なのは、WebApp用のiOSとAndroidだけであり、同じようにWebKitは両方のシステムエンジンだと思います。

— DavidTaubmann

それにもかかわらず、すべての商用ブラウザで採用されているクライアント側のストレージ標準はありません：html5rocks.com/en/features/storage

— DavidTaubmann

Safari 13では、以前のバージョンにあったWebSQLのサポートが削除されました。そのため、「ブラウザベンダーがこの技術の削除を要求したことも、削除する計画もありません」は事実ではありません。

— サンダー

@Thunderforge情報をありがとう！本当に知っておくといい！少し考えてみると、これがiOSの開発者にとって悪いことになるかどうかはわかりません。このツールは長年にわたって完全で有用なものでした。誰かがindexedDBにプロジェクトを再プログラミングするための費用を支払わない限り、MacまたはiOSデバイスを使用または購入しないことをユーザーに推奨する場合があります。

— DavidTaubmann

現実には、貢献者が規格の方向性に行き詰まりになっています。要するに、誰も同意できませんでした。

W3Cサイトでこれについて説明しています。

仕様は行き詰まりました：関係するすべての実装者は同じSQLバックエンド（Sqlite）を使用しましたが、標準化パスに沿って進むには複数の独立した実装が必要です。

WSCサイト

— htm11h
ソース

私にとって、これはどういうわけか、そのパスで標準化するものが他にないことに同意することを意味します。

— -DavidTaubmann

ベンダー固有の機能（包含、拡張、終了？）が許可されていないため、彼らはそれに同意しません。

— 苦境

次の文は、調査が継続していると述べているベンダー特有の好みのようなものだと思います。だから私はすべての当事者は、現在の状態に満足していないと確信しています...「Webアプリケーションワーキンググループは、他の二つのストレージ関連の仕様に関する作業続行します。WebストレージとインデックスデータベースのAPIを。」

— htm11h