query - HTML5 IndexedDB, Web SQL Database y guerras de navegador

indexeddb vs websql

Question

Estoy comenzando el desarrollo de una aplicación web con requisitos de almacenamiento de bases de datos fuera de línea. Para resumir, la aplicación debería poder ejecutarse:

• Uno de los principales navegadores de escritorio, Chrome preferido
• Safari en iOS
• Navegador nativo de Android (basado en V8 y WebKit)

Entonces, la pregunta es qué tecnología elegir: IndexedDB o Web SQL Database?

Con respecto a la base de datos web SQL, por un lado, está lista para ser utilizada en cualquiera de los escenarios anteriores. Por otro lado, Mozilla ha declarado que Firefox nunca lo implementará y, de acuerdo con el borrador de trabajo de HTML5 , la especificación ha llegado a un callejón sin salida:

Esta especificación ha llegado a un callejón sin salida: todos los implementadores interesados ​​han utilizado el mismo back-end SQL (Sqlite), pero necesitamos múltiples implementaciones independientes para avanzar a lo largo de una ruta de estandarización. Hasta que otro implementador esté interesado en implementar esta especificación, la descripción del dialecto SQL se ha dejado como una simple referencia a Sqlite, que no es aceptable para un estándar. Si usted es un implementador interesado en implementar un backend SQL independiente, póngase en contacto con el editor para que pueda escribir una especificación para el dialecto, permitiendo así que esta especificación avance.

IndexedDB es la alternativa promovida por Mozilla, pero solo vendrá en Firefox 4. Microsoft está interesado y Chrome también lo apoyará. No sé nada de los planes de Apple con respecto a IndexedDB.

Personalmente estoy inclinado a elegir la base de datos Web SQL, pero solo porque estoy acostumbrado a SQLite, me gusta el poder y la expresividad de SQL, y entiendo el modelo relacional. IndexedDB, para mí, es una incertidumbre.

Dicho esto, tengo miedo de apostar por el caballo equivocado. ¿Es seguro asumir que la base de datos Web SQL continuará existiendo, incluso si IndexedDB se convierte en el estándar?

(Una nota sobre CouchDB: ¿también la ven como una alternativa?)

Answer 1

¿Su base de datos necesita mucho más que las tiendas clave / de valor? Si no, he encontrado una serie de paquetes de JavaScript para la abstracción de bases de datos basadas en navegador local. Uno de esos paquetes es jStore:

http://code.google.com/p/jquery-jstore/

Recientemente lo utilicé para agregar almacenamiento local de clave / valor. Está bien documentado y el tiempo de integración fue insignificante: admite una variedad de backends de almacenamiento, incluido el almacenamiento local flash, a través de su API.

CouchDB es una solución excelente, para un problema que no es del todo congruente con el tuyo. Mira el móvil de couchone . No para estrictamente ''aplicaciones web'', pero puede proporcionar una base de datos con la que pueda ejecutar, si tiene cierta flexibilidad con las especificaciones.

Answer 2

Bueno, como con todo lo relacionado con la informática, el juego es "abstracción".

Si puede obtener una capa adecuada que funcione tanto en una tienda SQL como en una tienda de claves / valores, entonces, idealmente, estará aislado del problema y podrá soportar la implementación adecuada en el navegador en particular. Si su modelo de datos y patrones de acceso no concuerdan con el mínimo común denominador (es decir, una tienda ak / v), entonces eso resuelve su problema allí mismo.

Si puede usar cualquiera de las tiendas, entonces trabaje en una capa de acceso decente y aborde el problema desde esa dirección.

Ten en cuenta que el hecho de que tengas una tienda ak / v en el back-end no significa que tengas que modelar tus datos como solo un modelo ak / v. Esencialmente, todo lo que un DB está en el back-end es una tienda ak / v. Si no tiene una gran cantidad de datos, puede hacer muchas cosas. Con una gran cantidad de datos, es posible que los aros que deba atravesar le cuesten un rendimiento que posiblemente no vea con una cantidad de datos menor. Todo depende.

Answer 3

Con su requisito dado de Safari en iOS, no hay otra alternativa que WebSQL. WebSQL es compatible con otros navegadores móviles como Opera y Blackberry. No creo que eliminen el soporte WebSQL, incluso si tienen IndexedDB. De alguna manera son complementarios.

Por otro lado, en la guerra de almacenamiento de navegador, IndexedDB gana para siempre. IE y FF solo tendrán IndexedDB. Hecho irónico es que FF implementa IndexedDB encima de Sqlite.

Lo que me gustaría decir es que IndexedDB es más que una tienda de valores clave. Tiene índice y transacción. Estos dos solo hacen casi todas las características de la consulta SQL, incluidas join, conditional y sorting. No es obvio al principio debido a su API asíncrona.

El rendimiento de IndexedDB es mejor que WebSQL. Es mas seguro Es más flexible para el caso de uso de JavaScript. Por último, es más fácil de usar.

Para ilustrar el caso, usaré el código de sudo de mi biblioteca , pero puede usar IndexedDB API directamente:

La tienda ''people'' tiene el campo de índice ''name'' y lista el campo indexado ''hobby''. En JSON,

people = {
name: ''Foo Bar'',
email: ''[email protected]''
hobby: [''camping'', ''swimming'']};

Para recuperar el nombre de ''personas'' cuyo pasatiempo es ''acampar''.

var req = db.keys(''people'', ''hobby'', IDBKeyRange.only(''camping''));
req.done(function(campers) {
db.keys(''people'', campers, ''name'').done(function(names) {
console.log(names);
});
});

Lo interesante de este código es que no hay serialización involucrada. Por lo tanto, es muy rápido.

El siguiente ejemplo ilustra la consulta de gráficos de amistad. friendship tienda de objetos de friendship tiene solo un campo indexado enumerado friend_list . Utiliza la clave del almacén de objetos de personas como clave primaria fuera de línea. people tienda de objetos de people tiene muchos atributos, entre ellos el campo de location . La consulta es para encontrar la lista de amigos que me conocen y other_guy y que se encuentra en ''Singapur''.

var q1 = new ydn.db.Iterator(''friendship'', ''friend_list'', IDBKeyRange.only(me));
var q2 = new dn.db.Iterator(''friendship'', ''friend_list'', IDBKeyRange.only(other_guy));
// if location is not indexed, a filtered value query is used.
var q3 = new ydn.db.Iterator(''people'', new ydn.db.Expression([''"location"'', "''Singapore''", ''='']));
// if location is indexed, an index query is used.
// var q3 = new ydn.db.Iterator(''people'', ''location'', IDBKeyRange.only(''Singapore''));
var current_loop = 2; // start from inner loop
var join_algo = function(keys, index_keys) {
var advancement = [];
advancement[keys.length - 1] = null;
var has_adv = false;
for (var i = 0; i < keys.length; i++) {
if (!goog.isDef(keys[i])) {
// completed iterator
if (i != 0) {
advancement[i] = false; // request to restart the iteration
advancement[i - 1] = true; // advance outer iterator
current_loop = i - 1;
} // i == 0 means we are done.
has_adv = true;
break;
}
}
if (!has_adv) {
// continue looping current
advancement[current_loop] = true;
}
return advancement;
}
var result = db.scan([q3, q1, q2], join_algo);
result.done(function(keys, index_keys, values) {
console.log(values); // should get desire list of friends
});

De nuevo, esta consulta de unión es solo una exploración clave y, por lo tanto, muy rápida. De forma predeterminada, use el algoritmo de combinación clasificada para buscar claves que coincidan, pero aquí se muestra el algoritmo de combinación de bucle anidado. Entonces, la unión de tablas es posible, pero debe codificar el algoritmo de unión. Pero los algoritmos más nuevos como la combinación de zigzag son más rápidos que los posibles con Sqlite porque todas las entradas están ordenadas, los cursores pueden avanzar bien y, lo que es más importante, unirse al proceso puede explotar el conocimiento externo que no está en la base de datos. Con SQL, la operación de unión es opaca.

Aparte de IndexedDB, se pueden usar técnicas como la transmisión y el procesamiento de mapa / reducción.

Answer 4

Estoy respondiendo a esto en 2016 (5 años después de que hizo esta pregunta) y todo lo relacionado con la degradación de WebSQL sigue en pie . IndexedDB, por otro lado, cuenta con el respaldo de todos los principales proveedores de navegadores .

Entonces, para cualquier persona que se encuentre aquí enfrentando la misma decisión, acceda a IndexedDB.

Como lo implican otros aquí, sin embargo, tal decisión no es necesariamente necesaria; uno simplemente puede elegir (o crear) una biblioteca que utiliza la base de datos disponible en una máquina cliente.

BakedGoods difiere de las bibliotecas ya sugeridas aquí de varias maneras; lo más pertinente es que permite que el (los) tipo (s) de almacenamiento que se utilizarán se especifiquen explícitamente, lo que a su vez permite al desarrollador introducir otros factores (como las características de rendimiento) en el proceso de toma de decisiones.

Con él, la realización de operaciones de almacenamiento en cualquiera de los tipos de bases de datos es compatible con ...

... especificando las opciones de operación apropiadas y las configuraciones equivalentes para ambos tipos de bases de datos:

//If the operation is a set(), and the referenced structures
//don''t exist, they will be created automatically.
var webSQLOptionsObj = {
databaseName: "Example_DB",
databaseDisplayName: "Example DB",
databaseVersion: "",
estimatedDatabaseSize: 1024 * 1024,
tableData: {
name: "Main",
keyColumnName: "lastName",
columnDefinitions: "(lastName TEXT PRIMARY KEY, firstName TEXT)"
},
tableIndexDataArray: [name: "First_Name_Index", columnNames: "(firstName)"]
};
var indexedDBOptionsObj = {
databaseName: "Example_DB",
databaseVersion: 1,
objectStoreData: {
name: "Main",
keyPath: lastName,
autoIncrement: false
},
objectStoreIndexDataArray: [
{name: "First_Name_Index", keyPath: "firstName", unique: false, multiEntry: false}
],
};
var optionsObj = {
conductDisjointly: false,
webSQL: webSQLOptionsObj,
indexedDB: indexedDBOptionsObj
};

... y realizando la operación:

bakedGoods.set({
data: [
{value: {lastName: "Obama", firstName: "Barack"}},
{value: {lastName: "Biden", firstName: "Joe"}}
],
storageTypes: ["indexedDB", "webSQL"],
options: optionsObj,
complete: function(byStorageTypeStoredItemRangeDataObj, byStorageTypeErrorObj){}
});

Su interfaz simple y el soporte de instalaciones de almacenamiento sin igual se consiguen a costa de la falta de soporte para algunas configuraciones específicas de las instalaciones de almacenamiento. Por ejemplo, no admite la realización de operaciones de almacenamiento en tablas WebSQL con claves primarias de múltiples columnas.

Por lo tanto, si hace un uso intensivo de ese tipo de características, es posible que desee buscar en otra parte.

Ah, y por el bien de la total transparencia, BakedGoods es mantenido por los tuyos verdaderamente :).

Answer 5

Mi recomendación es ir a IndexDB , porque hay un IndexDB Polyfill disponible.

Todos los navegadores compatibles con WebSQL pueden admitir la API IndexDB de esta manera. A la inversa, sería muy difícil de implementar, por lo que si desea llegar a todos los navegadores que conocen algunas API de DB, IndexDB es la mejor opción en la actualidad.

Nota: Aunque esta pregunta es antigua, todavía es relevante, por lo que creo que las respuestas a esta pregunta merecen una actualización. Y lo siento por la solución de solo enlace, así que agregué solo enlaces a destinos usualmente duraderos: W3C y GitHub

Answer 6

Considerando que solo WebSQL soporta los tres requisitos que ha enumerado, ¿no debería ser simple su elección? No tiene idea de la hoja de ruta de desarrollo para Safari o Android, así que use lo que tiene disponible.