HTML5 IndexedDB, database SQL web e browser guerre

https://stackoverflow.com/questions/3971813

09-10-2019
|

Domanda

sto iniziando lo sviluppo di una web app con requisiti di storage del database non in linea. Lunga storia breve, l'applicazione dovrebbe essere in grado di funzionare su:

Uno dei principali browser desktop, Chrome ha preferito
Safari su iOS
del browser nativo di Android (basato sul V8 e WebKit)

Quindi la domanda è quale tecnologia scegliere:? IndexedDB o Web SQL Database

Per quanto riguarda Web SQL Database, da un lato, è pronto per essere utilizzato in tutti gli scenari di cui sopra. D'altra parte, Mozilla ha dichiarato Firefox non sarà mai la sua attuazione, e di tronchi con il progetto di HTML5 lavoro la specifica ha raggiunto un punto morto:

Questa specifica ha raggiunto un punto morto: tutti gli implementatori interessati hanno usato lo stesso back-end SQL (SQLite), ma abbiamo bisogno di più implementazioni indipendenti di procedere lungo un percorso di standardizzazione. Fino un'altra implementor interessa di attuazione della presente specifica, la descrizione del dialetto SQL è stata lasciata semplicemente come un riferimento a Sqlite, che non è accettabile per uno standard. Se siete un implementor interessati ad implementare un backend SQL indipendenti, si prega di contattare l'editor in modo che possa scrivere una specifica per il dialetto, permettendo così questa specifica di andare avanti.

IndexedDB è l'alternativa sostenuta da Mozilla, ma arriverà solo in Firefox 4. Microsoft è interessata e Chrome supporterà esso pure. Non so nulla di piani di Apple per quanto riguarda IndexedDB.

Sono personalmente incline a scegliere il Web SQL Database, ma solo perché mi sono abituato a SQLite, mi piace la potenza e l'espressività di SQL, e capisco il modello relazionale. IndexedDB, per me, è un'incertezza.

Detto questo, ho paura di scommettere sul cavallo sbagliato. È sicuro di assumere il supporto per database SQL web continuerà ad esistere, anche se IndexedDB diventa lo standard?

(Una nota su CouchDB:? Si fa vedere anche come alternativa)

Soluzione

Considerando solo WebSQL supporta tutti e tre i requisiti che hai elencato, non dovrebbe essere la vostra scelta semplice? Non hai spaccato la roadmap di sviluppo per Safari o Android, in modo da utilizzare quello che hai a disposizione.

Altri suggerimenti

Bene, come tutte le cose di calcolo, il gioco è "astrazione".

Se si può trovare con uno strato adeguata che funziona su entrambi un negozio di SQL e un negozio di chiave / valore, quindi, idealmente si stanno isolati dal problema e in grado di supportare l'implementazione appropriata sul browser particolare. Se il modello di dati e di accesso modelli non si adattano con il minimo comune denominatore (vale a dire un k / v negozio), quindi che praticamente risolve il problema proprio lì.

Se è possibile utilizzare negozio, poi il lavoro su un livello di accesso decente e affrontare il problema da quella direzione.

Mente, solo perché avete un k / v negozio sul back-end non significa che dovete modellare i dati come solo un k / v modello. Essenzialmente complesso un DB è sull'estremità posteriore è un k / v negozio. Se non si dispone di una quantità folle di dati, si possono fare molte cose. Con una grande quantità di dati i cerchi potrebbe essere necessario passare attraverso può costare in termini di prestazioni che si può anche non vedere con una minore quantità di dati. Tutto dipende.

I vostri esigenze di database in modo significativo al di là di negozi chiave / valore? In caso contrario, ho trovato un certo numero di pacchetti di javascript per locali astrazione del database basato su browser. Uno di questi pacchetti è jStore:

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

Recentemente ho usato per aggiungere storage chiave / valore locale. E 'ben documentato e il tempo di integrazione è stato trascurabile -. Supporta una vasta gamma di backend di memorizzazione, tra cui storage locale flash, attraverso la propria API

CouchDB è una soluzione eccellente - per un problema che non è del tutto congruente con la vostra. Scopri couchone cellulare . Non per rigorosamente 'applicazioni web', ma può fornire una base dati si potrebbe correre con, se si dispone di una certa flessibilità con la specifica.

La mia raccomandazione è di andare per IndexDB , perché c'è un IndexDB Polyfill disponibili.

Tutti i browser supportano WebSQL può supportare la IndexDB API questo modo. Il contrario sarebbe molto difficile da attuare, quindi se si vuole raggiungere tutti i browser che conoscono un po 'di DB API, IndexDB è la scelta migliore di oggi.

Nota: Anche che questa domanda è vecchio è ancora rilevante, quindi penso che le risposte a questa domanda merita un aggiornamento. E dispiace per la soluzione di collegamento solo, così ho aggiunto solo i collegamenti per le destinazioni di solito lunga durata: W3C e GitHub

Con la vostra data esigenza di Safari su iOS, non c'è alternativa, ma WebSQL. WebSQL è supportato in altro browser mobile come Opera e Blackberry. Non credo che rimuoverà il supporto WebSQL anche se hanno IndexedDB. In qualche modo sono complementari.

D'altra parte, sulla guerra di archiviazione del browser, IndexedDB vincere per il bene. IE e FF sarà solo hanno IndexedDB. Infatti ironica è che FF implementa IndexedDB in cima SQLite.

Quello che vorrei dire è IndexedDB è più di un semplice negozio di valore della chiave. Ha indice e transazione. Questi solo due fare quasi tutte le funzionalità di query SQL tra cui unirsi, condizionale e l'ordinamento. Non è evidente a prima a causa della sua API asincrona.

Performance di IndexedDB è meglio di WebSQL. E 'più sicuro. E 'più flessibile per caso d'uso di JavaScript. Infine è più facile da usare.

Per illustrare il caso, io userà sudo codice mia biblioteca , ma è possibile utilizzare IndexedDB API direttamente:

Conservare la 'gente' ha campo indice 'nome' e la lista campo indicizzato 'il mio hobby'. In JSON,

people = {
  name: 'Foo Bar',
  email: 'foo@bar.com'
  hobby: ['camping', 'swimming']};

per recuperare il nome dal 'popolo' il cui hobby è 'camping'.

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

cosa interessante di questo codice è che non c'è serializzazione coinvolti. Quindi è molto veloce.

Il seguente esempio illustra interrogazione amicizia grafico. negozio oggetto friendship ha solo uno elencato campo friend_list indicizzato. Si usa le persone oggetto chiave negozio come chiave primaria out-of-line. archivio degli oggetti people ha molti attributi, tra i quali è il campo location. La query è quello di trovare l'elenco degli amici che conoscono me e other_guy e si trova in 'Singapore'.

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 
});

Anche questo join interrogazione è solo scansione chiave e quindi molto veloce. Con l'utilizzo scan impostazione predefinita algoritmo ordinati-merge per trovare le chiavi di corrispondenza, ma qui mostrare ingenuo nested-loop join algoritmo. Così tavolo Partecipare è possibile, ma è necessario il codice unirsi algoritmo. Ma gli algoritmi più recenti come a zig-zag merge sono più veloci di quanto possibile con Sqlite perché tutti gli ingressi sono ordinati, i cursori possono avanzare al bene e cosa ancora più importante unire processo in grado di sfruttare la conoscenza esterna che non è nel database. Con SQL, join è opaco.

Oltre a questo IndexedDB può essere utilizzato tecniche come lo streaming e mappa / ridurre la trasformazione.

Sto rispondendo a questo nel 2016 (5 anni dopo aver fatto questa domanda) e tutto ciò che riguarda il deprecazione di WebSQL si ferma . IndexedDB d'altra parte, gode del sostegno di tutti i principali browser vendor .

Quindi, per tutti coloro che possono trovarsi di fronte a qui la stessa decisione di fare, andare con IndexedDB.

Come implicita da altri qui, tuttavia, una tale decisione non è uno che deve necessariamente essere fatta; si può semplicemente scegliere (o fare) una libreria che utilizza a seconda di quale banca dati è disponibile su una macchina client.

BakedGoods differisce da tali librerie già suggerito qui in diversi modi; più pertinente, permette il tipo di archiviazione (s) che devono essere utilizzate per essere esplicitamente specificato, a sua volta, permettendo agli sviluppatori di introdurre altri fattori (come le caratteristiche di prestazione) per il processo decisionale.

Con esso, lo svolgimento di operazioni di stoccaggio in qualsiasi dei tipi di database è supportato è una questione di ...

... specificando le opzioni di funzionamento appropriati e configurazioni equivalenti per entrambi i tipi di database:

//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
};

... e condurre l'operazione:

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

La sua interfaccia semplice e il supporto impianto di stoccaggio senza pari viene al costo di mancanza di supporto per alcune configurazioni impianto-specifici di stoccaggio. Ad esempio, non supporta la conduzione delle operazioni di stoccaggio in tabelle WebSQL con chiavi primarie multi-colonna.

Quindi, se si fanno largo uso di questi tipi di caratteristiche, si consiglia di guardare altrove.

Oh, e per il bene di una completa trasparenza, BakedGoods è mantenuto dal sottoscritto :).

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow