¿Por qué la base de datos Web SQL está en desuso?

Estoy haciendo una aplicación de Android híbrida.

Al principio decidí usar localStorage, después de pasar 2 días, me di cuenta de que es muy extraño y lo dejé.

Luego, recogí indexedDB, después de pasar todo el día de hoy y obtener el resultado en Google Chrome, no se ejecuta dentro de un WebView de la aplicación de Android.

Y nunca usé la base de datos Web SQL porque estaba en desuso. De todos modos, me di cuenta de que PhoneGap todavía usa Web SQL y los navegadores de Android lo admiten.

¿Por qué se desactivó Web SQL en primer lugar? ¿Y será una buena idea para mí ir con Web SQL ahora?

— mosquito
fuente

¿Qué te pareció extraño de localStorage? Es solo una tienda de pares clave / valor. Tengo curiosidad por saber qué no le gustó y el tipo de problemas que tuvo. Lo estoy usando en un proyecto y me gustaría saber el problema del caso con el que te encontraste.

— jmq

@oligofren, si está utilizando SQL más que un simple cerebro en web SQL, no puede traducirlo exactamente a localStorage y etc.

— Pacerier

Pero ahórrese la molestia de crear una capa de abstracción (que hice), y solo use YDN-DB por ahora dev.yathit.com/ydn-db/index.html . Utilizará la mejor tecnología disponible para ese dispositivo.

— oligofren

Siempre está utilizando una capa de abstracción de algún tipo. Esa es la programación y cómo lograr un comportamiento consistente independientemente de los errores de implementación en el navegador. Las llamadas ficticias js superan los 5000 por ms, por lo que, a menos que el autor de YDN-DB haya hecho algo ridículamente estúpido, no debería verse afectado por un rendimiento cercano al orden de 100 ms. Más como 1ms, para operaciones 1: 1, en plataformas que no admiten IndexedDB de forma nativa. Que, por el momento, son solo versiones anteriores. Todos los navegadores actuales son compatibles con IndexedDB. WebSQL está en desuso. Y pruebe algunos perfiles simples antes de "optimizar" la tecnología de distancia :-)

— oligofren

@oligofren, te estás perdiendo el punto de mi comentario. No estoy hablando de la sobrecarga de una función que llama a otra y viceversa. Digo que cuando usa una capa de abstracción db, se limita a un subconjunto de patrones de consulta SQL que puede usar sin sufrir penalizaciones de rendimiento. No puede realizar ajustes porque la biblioteca lo hace automáticamente y no siempre lo hace correctamente. No será de 1 ms a menos que almacene solo 1 fila de datos.

— Pacerier

Respuestas:

100

Versión corta: Web SQL quedó en desuso porque los estándares son realmente importantes y convertir Web SQL en un estándar adecuado habría sido prohibitivamente difícil.

Dado que las implementaciones existentes de Web SQL son básicamente envolturas alrededor de SQLite, cualquier intento de definir un estándar del mismo era básicamente "hacer lo que hace SQLite". Esto no es lo suficientemente bueno; un verdadero estándar debe ser autónomo, para definir la interfaz y los casos de esquina y las excepciones en sí, en lugar de apuntar a una implementación existente (especialmente una implementación de terceros como SQLite). De lo contrario, corre el riesgo de tomar las peculiaridades de una implementación en particular y consagrarlas como estándar. Por lo que he leído, el W3C prefiere múltiples implementaciones independientes de los estándares propuestos para ayudar a asegurar que esto suceda; como Web SQL estaba tan vinculado a SQLite, eso simplemente no iba a suceder.

El blog de Mozilla da más detalles sobre su razonamiento en particular para no admitir Web SQL; aparentemente fueron una de las principales voces en desaprobar Web SQL.

¿Deberías ir con Web SQL ahora? No espero que los proveedores que actualmente lo admiten (como Google y Apple) lo eliminen pronto, pero IE y Firefox no lo agregarán, y dado que está en desuso, ¿por qué invertir en él? (Por ejemplo, Ido Green , con Google Developer Relations, no recomienda usarlo).

— Josh Kelley
fuente

Esa publicación de Ido es súper básica y ni siquiera rasca la superficie sobre por qué uno debería usar uno u otro. El hecho es que las bases de datos noSQL se diseñaron teniendo en cuenta el gran tamaño, y eso simplemente no se aplica a una base de datos que se ejecuta en la computadora de un usuario. Puede obtener algunas ventajas relevantes para big data, pero pierde cosas como JOIN. De ninguna manera podría haber desarrollado mi extensión de cromo "Plus for Trello" de código abierto si tuviera que usar indexedDb (y uso el almacén de datos noSQL en appengine), así que elegí web sql.

— Zig Mandel

Debido a que el competidor de Google GMail MS-Outlook podría hacer una búsqueda de texto completo, y porque "aceptar, extender, exterminar" no es posible cuando solo hay una implementación de SQLite (MS), y porque a Jonas Sicking (Mozilla) no le gusta SQL. Los almacenes de valores clave con una interfaz demasiado complicada son, por supuesto, mucho mejores (también conocidos como guiones), especialmente porque cada objeto JavaScript ya es una matriz asociativa. Y seamos sinceros, la normalización de datos, la integridad referencial y las operaciones basadas en conjuntos realmente son repugnantes para alguien que no (quiere) entender SQL, también conocido como "Los usuarios no quieren SQL".

— Dilema el

Irónicamente, WebSQL es perfecto para interactuar con SQLite si eso es exactamente lo que quieres hacer (y no necesitas PRAGMA).

— Michael

entonces, Mozilla mató un proyecto y una tecnología que fue extremadamente útil en muchas situaciones porque a algunas personas no les gustó y la gente los defendió. ¿Por qué? podrían implementar AMBOS IndexedDB Y WebSQL

— yoyo_fun

Safari 13 ahora ha eliminado el soporte para WebSQL que tenían versiones anteriores.

— Thunderforge

La respuesta de Josh Kelley es hasta ahora la MEJOR respuesta que he encontrado sobre la razón del trabajo estándar que se debe detener. Dicho esto, creo que hay una perspectiva adicional a considerar con respecto a la base de usuarios.

Sin embargo, no estoy de acuerdo con el enfoque de Ido Green sobre el tema ("Esta es una recomendación para que los desarrolladores web ya no usen la tecnología de manera tan efectiva") ...

Creo (como afirma vi4m en los comentarios del artículo de Ido Green):

Nosotros (los desarrolladores) aún podemos usar esta tecnología. Ningún proveedor de navegadores solicitó la eliminación de esta tecnología, ni planea eliminarla. Los desarrolladores son la voz de la web. Podemos seguir usándolo, tal vez Mozilla cambie de opinión ;-)

Y agregaría otro enfoque lógico: si está desarrollando para entornos móviles ... ¿qué ambientes están en más manos? Respuesta: iOS y Android ... Entonces, si AMBOS son compatibles con webSQL, y su objetivo es MÓVIL MASIVO, ¡adelante!

Piense como las grandes aplicaciones lo han hecho casi siempre al principio, obtenga la MAYORÍA primero, luego (una vez que haya logrado el éxito) vuelva a crear el trabajo para obtener la menor cantidad restante (si realmente desea lograrlas o se le pide que lo haga). Finalmente, ¿no es siempre el éxito quien marca el camino?

Después de leer el artículo de Nolan Lawson (en el que está claro su intención de darle una oportunidad a su invención) creo que este asunto se convirtió en una nueva guerra fría entre gigantes tecnológicos que ni siquiera debería existir. Creo que las especificaciones están hechas para permanecer (lo más largo y lo más intacto posible) para el mejor rendimiento orientado al cliente. Irónicamente, el trabajo de "especificaciones técnicas" es generar NUEVAS especificaciones (a veces donde no se necesita ninguna, para que pueda tener algo más que hacer), y de la misma manera, los trabajos de los programadores a veces se centran en cambiar y reescribir lo que ya funciona en lugar de hacer soluciones para nuevos problemas. y nuevas tendencias.

Para mí, las bases de datos del lado del cliente consistían simplemente en hacer paralelos (entre el lado del servidor y el del cliente) para que pudiéramos crear, almacenar, cargar y descargar datos fácilmente. Según este enfoque, tener los mismos lenguajes y estructuras (al menos para nosotros, los desarrolladores de código abierto de LAMP) es sencillo y lógico.

Creo que la intención de IndexedDB de ser una alternativa con posibilidades más amplias y nuevas es siempre un buen enfoque, pero de alguna manera se parece a la necesidad de desarrollar software que NECESITA instalarse (incluso cuando la solución central puede permanecer en la nube). En un mundo que tiende a mantenerse conectado, suena como A) una cuestión de control y posesión o B) enfocándose en desarrollar monstruos para el lado del cliente ... pero para ese tipo de necesidades existen aplicaciones (en el mundo móvil) y software (en el mundo de la PC). Creo que el objetivo de Webapps debería ser principalmente extender la web sin importar el dispositivo.

Creo que una buena infografía podría salir de este enfoque.

— DavidTaubmann
fuente

Tenga en cuenta que las versiones recientes de Firefox e IE no son compatibles con WebSQL.

— ocodo

Que yo sepa, nunca han admitido WebSQL. Puede verificar eso aquí: [link] caniuse.com/#feat=sql-storage . El único que me sorprende es Opera Mini, están perdiendo mercado de esta manera. De todos modos, para mí, como desarrollador, los únicos que importan son iOS y Android para WebApps, y de todos modos WebKit, que creo que es el motor de ambos sistemas.

— DavidTaubmann

Sin embargo, no todos los navegadores comerciales han adoptado un estándar de almacenamiento del lado del cliente: html5rocks.com/en/features/storage

— DavidTaubmann

Safari 13 ahora ha eliminado el soporte para WebSQL que tenían versiones anteriores. Por lo tanto, "Ningún proveedor de navegadores solicitó la eliminación de esta tecnología, ni planea eliminarla" ya no es cierto.

— Thunderforge

@ Thunderforge ¡Gracias por la información! Muy bueno saberlo! Pensando un poco, no sé si esto va a ser malo para los desarrolladores o peor para iOS, ya que esta herramienta ha sido completa y útil para nosotros desde hace muchos años. Podríamos recomendar a nuestros usuarios que no usen ni compren más dispositivos Mac o iOS, a menos que alguien pague los costos de reprogramar los proyectos a indexedDB.

— DavidTaubmann

La realidad es que las partes contribuyentes llegaron a un punto muerto en la dirección de la norma. En resumen, nadie podría estar de acuerdo.

El sitio W3C explica esto.

La especificación llegó a un punto muerto: todos los implementadores interesados han utilizado el mismo backend SQL (Sqlite), pero necesitamos múltiples implementaciones independientes para avanzar a lo largo de una ruta de estandarización.

Sitio de la CSM

— htm11h
fuente

Para mí, esto de alguna manera significa que están de acuerdo en que no hay nada más que estandarizar en ese camino ... Funciona bien de la manera en que lo está porque conecta el camino del estándar con una tecnología de terceros existente que debería / no estar estandarizada por ellos.

— DavidTaubmann

Para mí, eso suena como: No estaban de acuerdo, porque no permite características específicas del proveedor (¿abrazar, extender, exterminar?).

— Dilema

Creo que es algún tipo de preferencia específica del proveedor, la siguiente oración dice que la investigación continúa. Así que no estoy seguro de todas las partes estaban satisfechos con el estado actual ... "El Grupo de Trabajo de Aplicaciones Web continúa el trabajo en otras dos especificaciones relacionadas con el almacenamiento: almacenamiento Web y API de base de datos indexada."

— htm11h