it-swarm.com.de

Warum ist die Web SQL-Datenbank veraltet?

Ich mache eine Hybrid Android App.

Zuerst habe ich mich für localStorage entschieden. Nachdem ich 2 Tage verbracht hatte, stellte ich fest, dass es sehr seltsam ist und ließ es fallen.

Dann habe ich indexedDB aufgegriffen, nachdem ich den ganzen Tag damit verbracht habe, die Ausgabe in Google Chrome zu erhalten, läuft sie nicht in einer WebView der App Android App).

Und ich habe die Web SQL-Datenbank überhaupt nicht verwendet, weil sie veraltet war. Jedenfalls ist mir aufgefallen, dass PhoneGap immer noch Web SQL verwendet und die Browser von Android dies unterstützen.

Warum wurde Web SQL überhaupt nicht mehr unterstützt? Und wird es für mich eine gute Idee sein, jetzt mit Web SQL zu arbeiten?

97
user52009

Kurzversion: Web SQL wurde veraltet, weil Standards wirklich wichtig sind und es unerschwinglich schwierig gewesen wäre, Web SQL in einen richtigen Standard zu verwandeln.

Da vorhandene Implementierungen von Web SQL im Grunde genommen Wrapper um SQLite sind, war jeder Versuch, einen Standard davon zu definieren, im Grunde "tun, was SQLite tut". Das ist nicht gut genug; Ein echter Standard muss in sich geschlossen sein, um die Schnittstellen- und Eckfälle und Ausnahmen selbst zu definieren, anstatt auf eine vorhandene Implementierung zu verweisen (insbesondere auf eine Implementierung eines Drittanbieters wie SQLite). Andernfalls laufen Sie Gefahr, die Macken einer bestimmten Implementierung als Standard zu verankern. Nach dem, was ich gelesen habe, bevorzugt das W3C mehrere unabhängige Implementierungen der vorgeschlagenen Standards, um sicherzustellen, dass dies geschieht. Da Web SQL so an SQLite gebunden war, würde das einfach nicht passieren.

Mozillas Blog enthält weitere Einzelheiten zu ihren Argumenten, insbesondere für die Nichtunterstützung von Web SQL. Anscheinend waren sie eine der Hauptstimmen, wenn es darum ging, Web SQL zu verwerfen.

Sollten Sie jetzt mit Web SQL gehen? Ich erwarte nicht, dass die Anbieter, die es derzeit unterstützen (wie Google und Apple), es bald löschen, aber IE und Firefox werden es nicht hinzufügen, und da es veraltet ist, warum In sie investieren? (Beispiel: Ido Green empfiehlt bei Google Developer Relations die Verwendung nicht.)

102
Josh Kelley

Josh Kelleys Antwort ist bis jetzt die BESTE Antwort, die ich je über den Grund für die Einstellung der Standardarbeit gefunden habe. Trotzdem denke ich, dass es eine zusätzliche Perspektive gibt, die in Bezug auf die Benutzerbasis berücksichtigt werden muss.

Trotzdem bin ich nicht einverstanden mit Ido Green's Herangehensweise an das Thema ("Dies ist eine Empfehlung für Webentwickler, die Technologie nicht mehr so ​​effektiv zu nutzen") ...

Ich glaube (wie vi4m in den Kommentaren des Artikels von Ido Green feststellt):

Wir (Entwickler) können diese Technologie weiterhin verwenden. Kein Browserhersteller hat die Entfernung dieser Technologie angefordert und plant auch nicht, sie zu entfernen. Entwickler sind die Stimme des Webs. Wir können es einfach noch benutzen, vielleicht wird Mozilla es sich anders überlegen ;-)

Und ich würde noch einen weiteren logischen Ansatz hinzufügen: Wenn Sie für mobile Umgebungen entwickeln ... ¿Welche Umgebungen sind in mehr Händen? Antwort: iOS und Android ... Wenn BEIDE webSQL unterstützen und Ihr Ziel MASSIVE MOBILE ist, machen Sie es!

Denken Sie, wie große Apps es fast immer am Anfang getan haben, holen Sie sich zuerst die MEISTEN und erstellen Sie dann (sobald Sie Erfolg haben) die Arbeit neu, um die verbleibenden weniger zu erhalten (wenn Sie sie wirklich erreichen möchten oder dazu aufgefordert werden). Schließlich nicht immer Erfolg, wer den Weg markiert?


Nachdem ich Nolan Lawsons Artikel gelesen habe (in dem klar ist, dass er beabsichtigt, seiner Erfindung eine Chance zu geben), glaube ich, dass diese Angelegenheit zu einem neuen Kalten Krieg zwischen Technologiegiganten wurde, der nicht einmal existieren sollte. Ich glaube, dass die Spezifikationen so gestaltet sind, dass sie bleiben (so lange und unberührt wie möglich - umso besser für eine kundenorientierte Leistung). Ironischerweise besteht die Aufgabe von "specs guys" darin, NEUE Spezifikationen zu generieren (manchmal dort, wo keine benötigt werden, damit er etwas mehr zu tun hat), und ebenso konzentrieren sich Programmiererjobs manchmal darauf, das zu ändern und neu zu schreiben, was bereits funktioniert, anstatt Lösungen für neue Probleme zu finden und neue Tendenzen.

Für mich ging es bei clientseitigen Datenbanken nur darum, Parallelen (zwischen Server- und Client-Seite) zu ziehen, damit wir Daten einfach erstellen, speichern, hochladen und herunterladen können. Bei diesem Ansatz ist es einfach und logisch, dieselben Sprachen und Strukturen zu haben (zumindest für uns LAMP OpenSource-Entwickler).

Ich glaube, dass die Absicht von IndexedDB, eine Alternative mit breiteren und neueren Möglichkeiten zu sein, immer ein guter Ansatz ist, aber irgendwie ähnelt es für mich der Notwendigkeit, Software zu entwickeln, die installiert werden muss (selbst wenn die Kernlösung in der Cloud bleiben kann). In einer Welt, die dazu neigt, in Verbindung zu bleiben, klingt es wie A) eine Frage der Kontrolle und des Besitzes oder B) sich darauf zu konzentrieren, Monster für den Kunden zu entwickeln ... aber für diese Art von Anforderungen gibt es Apps (in der mobilen Welt) und Software (in der PC-Welt). Ich glaube, das Ziel von Webapps sollte hauptsächlich darin bestehen, das Web unabhängig vom Gerät zu erweitern.

Ich glaube, eine schöne Infografik könnte aus diesem Ansatz hervorgehen.

17
DavidTaubmann

Die Realität ist, dass die beteiligten Parteien eine Sackgasse in Richtung des Standards erreicht haben. Kurz gesagt, niemand konnte zustimmen.

Die W3C-Site erklärt dies.

Die Spezifikation erreichte eine Sackgasse: Alle interessierten Implementierer haben dasselbe SQL-Backend (Sqlite) verwendet, aber wir benötigen mehrere unabhängige Implementierungen, um auf einem Standardisierungspfad fortzufahren.

WSC-Site

1
htm11h