HTML5 IndexedDB, Web SQL-Datenbank und Browser-Kriege

StackOverflow https://stackoverflow.com/questions/3971813

  •  09-10-2019
  •  | 
  •  

Frage

Ich fange die Entwicklung eines Web-App mit Offline-Datenbank Speicheranforderungen. Lange Rede kurzer Sinn, sollte die App der Lage sein, laufen auf:

  • Eine der wichtigsten Desktop-Browser, Chrome bevorzugt
  • Safari auf iOS
  • Android nativen Browser (basierend auf V8 und WebKit)

Die Frage ist also, welche Technologie zu wählen:? IndexedDB oder Web-SQL-Datenbank

In Bezug auf Web-SQL-Datenbank, auf der einen Seite, ist es bereit, in eine der oben genannten Szenarien verwendet werden. Auf der anderen Seite hat Mozilla Firefox angegeben wird es nie implementieren und Acording zum HTML5 Arbeitsentwurf die Spezifikation hat in eine Sackgasse geraten:

Diese Angabe hat in eine Sackgasse geraten: alle interessierten Implementierer verwendet haben die gleiche SQL-Backend (SQLite), aber wir brauchen mehrere unabhängige Implementierungen entlang einer Standardisierung Weg zu gehen. Bis ein anderer Implementierer bei der Umsetzung dieser Spezifikation interessiert ist, hat sich die Beschreibung des SQL-Dialekt als einfach einen Verweis auf SQLite links, die für einen Standard nicht akzeptabel ist. Sollten Sie eine Implementierer bei der Umsetzung einen unabhängigen SQL-Backend interessiert sein, kontaktieren Sie bitte den Editor so, dass er eine Spezifikation für den Dialekt schreiben, so dass diese Spezifikation vorwärts zu bewegen.

IndexedDB ist die Alternative von Mozilla befürwortet wird, aber es wird kommen nur in Firefox 4. Microsoft interessiert und Chrome wird es auch stützen. Ich weiß nichts von Apples Pläne für IndexedDB.

Ich persönlich geneigt Web SQL-Datenbank zu wählen, aber nur, weil ich zu SQLite verwendet, ich mag die Kraft und Ausdrucksstärke von SQL, und ich verstehe das relationale Modell. IndexedDB, für mich ist eine Unsicherheit.

Das heißt, ich habe Angst, auf das falsche Pferd zu wetten. Ist es sicher Unterstützung für Web-SQL-Datenbank zu übernehmen wird weiterhin bestehen, auch wenn IndexedDB der Standard wird?

(Ein Hinweis auf CouchDB:? Sie auch Sie es als Alternative sehen)

War es hilfreich?

Lösung

Unter Berücksichtigung unterstützt nur WebSQL alle drei Anforderungen, die Sie aufgeführt haben, sollte Ihre Wahl nicht einfach sein? Sie haben keinen Einblick in den Entwicklungs-Roadmap für Safari oder Android, so verwenden, was Sie zur Verfügung haben.

Andere Tipps

Nun, wie bei allen Dingen Computing, das Spiel ist "Abstraktion".

Wenn Sie mit einer ausreichenden Schicht kommen können, dass beiden Werke auf einen SQL-Speicher und einen Schlüssel / Wert-Speicher, dann, im Idealfall sind Sie von dem Problem isoliert und können die entsprechende Umsetzung auf dem bestimmten Browser unterstützt. Wenn Ihr Datenmodell und Zugriffsmuster passen nicht mit dem kleinsten gemeinsamen Nenner (das heißt eine k / v Speicher), dann ist das so ziemlich löst Ihr Problem genau dort.

Wenn Sie entweder Speicher verwenden können, dann die Arbeit an einem anständigen Zugriffsschicht und nähern sie das Problem aus dieser Richtung.

Geist, nur weil Sie einen k / v-Speicher auf dem Back-End haben, bedeutet nicht, dass Sie Ihre Daten als nur ein k / v Modell modellieren müssen. Im wesentlichen alles eine DB ist auf der Back-End-a k / v Speicher ist. Wenn Sie nicht über eine unglaubliche Menge von Daten haben, können Sie viele Dinge tun. Mit einer großen Datenmenge HOOPS die Sie könnten Sie springen durch Leistungs kosten können, dass Sie kann auch nicht mit einer geringeren Menge an Daten sehen. Alles hängt.

Sind Ihre Datenbankanforderungen deutlich über Schlüssel / Wert speichert? Wenn nicht, ich habe eine Reihe von Javascript-Pakete für lokale Browser-basierte Datenbank-Abstraktions gefunden. Ein solches Paket ist jStore:

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

Ich habe es vor kurzem lokale Schlüssel / Wert-Speicher hinzuzufügen. Es ist gut dokumentiert, und die Integrationszeit war vernachlässigbar -. Es eine Reihe von Backends unterstützt, einschließlich Flash lokalen Speicher über seine API

CouchDB ist eine ausgezeichnete Lösung - für ein Problem, das nicht ganz mit Ihnen kongruent ist. Schauen Sie sich couchone Mobil . Nicht für streng ‚Web-Anwendungen‘, aber es kann eine Datenbank Fundament bieten Ihnen laufen könnte, wenn man eine gewisse Flexibilität bei der Spezifikation haben.

Meine Empfehlung ist, auf geht für IndexDB , weil es ein IndexDB Polyfill zur Verfügung.

Alle Browser unterstützen WebSQL können die IndexDB API auf diese Weise unterstützen. Andersherum wäre sehr schwierig, so zu implementieren, wenn Sie alle Browser erreichen wollen, die über einige DB-API wissen, IndexDB ist die beste Wahl heute.

Hinweis: Auch, dass diese Frage alt ist es immer noch relevant ist, so dass ich die Antworten auf diese Frage denke Update verdienen. Und sorry für die Link-only Lösung, so dass ich nur hinzugefügt Links zu in der Regel lang anhaltende Ziele: W3C und GitHub

Mit Ihrer gegebenen Anforderung von Safari auf iOS, gibt es keine andere Möglichkeit, als WebSQL. WebSQL in anderen mobilen Browser wie Opera und Blackberry unterstützt. Ich glaube nicht, dass sie WebSQL Unterstützung entfernen, auch wenn sie IndexedDB haben. Irgendwie sind sie ergänzen einander.

Auf der anderen Seite, auf Browser-Speicher Krieg gewinnt IndexedDB für gut. IE und FF nur IndexedDB haben. Ironic Tatsache ist, dass FF implementiert IndexedDB oben auf SQLite.

Was würde ich sagen, ist IndexedDB mehr ist als nur Schlüsselwert zu speichern. Es hat den Index und Transaktion. Diese nur zwei macht fast alle Features von SQL-Abfrage einschließlich verbinden, bedingte und Sortierung. Es ist nicht offensichtlich zunächst wegen seiner asynchronen API.

Performance von IndexedDB ist besser als WebSQL. Es ist sicherer. Es ist flexibler für Javascript Anwendungsfall. Schließlich ist es einfacher zu bedienen.

, um den Fall zu verdeutlichen, werde ich Sudo-Code von meiner Bibliothek , aber Sie verwenden können, IndexedDB API direkt:

Das ‚Volk‘ Speicher hat Indexfeld ‚Name‘ und Liste indizierter Feld ‚Hobby‘. In JSON 

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

Um Namen von ‚Menschen‘, dessen Hobby ‚Camping‘ abgerufen werden. 

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

Interessante an diesem Code gibt es keine Serialisierung beteiligt ist. Daher ist es sehr schnell.

Das folgende Beispiel veranschaulichen Freundschaft Graph Query. friendship Objektspeicher hat nur einen aufgelistet indizierten Feld friend_list. Es verwendet Menschen Objektspeicher Schlüssel als Out-of-line Primärschlüssel. people Objektspeicher hat viele Attribute, darunter location Feld ist. Die Abfrage ist die Liste der Freunde finden, die me und other_guy und befindet sich in ‚Singapur‘ kennen. 

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

Auch hier kommt diese Abfrage nur Tastenabtastleitung ist und daher sehr schnell. Standardmäßig scan Verwendung sortiert-Merge-Algorithmus zu finden Schlüsseln entsprechen, aber hier zeigen naive Nested-Loop-Join-Algorithmus. So Tisch Beitritt ist möglich, aber Sie müssen Code-Algorithmus JOIN. Aber neuere Algorithmen wie Zick-Zack-merge sind schneller als möglich mit SQLite, weil alle Eingänge sortiert sind, Cursor auf gut voranbringen können und was noch wichtiger Prozess teilnehmen können externes Wissen nutzen, die nicht in der Datenbank ist. Mit SQL Join-Operation undurchsichtig ist.

Anders als das IndexedDB verwendet werden können Techniken wie Streaming und Map / Reduce-Verarbeitung.

Ich bin im Jahr 2016 auf diese Antwort (5 Jahre, nachdem Sie diese Frage gestellt) und alles über die deprecation von WebSQL steht noch . IndexedDB auf der anderen Seite genießt die Unterstützung von all den großen Browser-Anbieter .

So für jeden, der hier finden sich mit der gleichen Entscheidung konfrontiert zu machen, gehen mit IndexedDB.

Wie implizierten andere hier jedoch eine solche Entscheidung nicht eine, die unbedingt gemacht werden muss; man kann einfach wählen (oder make) eine Bibliothek, die nutzt Unabhängig davon, welche Datenbank auf einem Client-Computer verfügbar ist.

bakedgoods unterscheidet sich von solchen Bibliotheken bereits vorgeschlagen, hier in mehrfacher Hinsicht; die meisten einschlägig, ermöglicht es den Speichertyp (en), die verwendet werden soll, explizit angegeben werden, die wiederum ermöglicht den Entwickler andere Faktoren einzuführen (wie Leistungsmerkmale) in der Entscheidungsfindung.

Damit die Durchführung Speicheroperationen in welchen auch immer der Datenbanktypen unterstützt wird, ist eine Frage der ...

... die entsprechenden Bedienoptionen spezifizieren und äquivalente Konfigurationen für beiden Datenbanktypen: 

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

... und der Betrieb der Durchführung: 

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

Die einfache Schnittstelle und unübertroffene Lager Unterstützung kommt auf Kosten des Mangels an Unterstützung für einige Speicheranlagenspezifische Konfigurationen. Zum Beispiel ist es nicht die Leitung der Speichervorgänge in WebSQL Tabellen mit mehrspaltigen Primärschlüsseln unterstützen.

Wenn Sie also die starke Nutzung dieser Arten von Funktionen machen, können Sie an anderer Stelle suchen.

Oh, und im Interesse der vollständigen Transparenz wird bakedgoods von Ihnen gepflegt wirklich :).

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top