45 votes

HTML5 IndexedDB, Web SQL Database et guerres des navigateurs

Je commence le développement d'une application web avec des exigences de stockage de base de données hors ligne. Pour faire court, l'application doit pouvoir fonctionner sur :

  • L'un des principaux navigateurs de bureau, Chrome de préférence.
  • Safari sur iOS
  • Le navigateur natif d'Android (basé sur V8 et WebKit)

La question est donc de savoir quelle technologie choisir : IndexedDB ou Web SQL Database ?

En ce qui concerne la base de données Web SQL, d'une part, elle est prête à être utilisée dans tous les scénarios ci-dessus. D'autre part, Mozilla a déclaré que Firefox ne l'implémentera jamais, et selon le HTML5 projet de travail la spécification est dans une impasse :

Cette spécification est dans une impasse : tous les implémenteurs intéressés ont utilisé le même backend SQL (Sqlite), mais nous avons besoin de plusieurs implémentations indépendantes pour avancer sur la voie de la standardisation. Jusqu'à ce qu'un autre implémenteur soit intéressé par l'implémentation de cette spécification, la description du dialecte SQL a été laissée comme une simple référence à Sqlite, ce qui n'est pas acceptable pour un standard. Si vous êtes un implémenteur intéressé par l'implémentation d'un backend SQL indépendant, veuillez contacter l'éditeur afin qu'il puisse écrire une spécification pour le dialecte, permettant ainsi à cette spécification de progresser.

IndexedDB est l'alternative préconisée par Mozilla, mais elle n'arrivera que dans Firefox 4. Microsoft s'y intéresse et Chrome le supportera également. Je ne sais rien des plans d'Apple concernant IndexedDB.

Je suis personnellement enclin à choisir Web SQL Database, mais juste parce que je suis habitué à SQLite, j'aime la puissance et l'expressivité de SQL, et je comprends le modèle relationnel. IndexedDB, pour moi, est une incertitude.

Cela dit, j'ai peur de parier sur le mauvais cheval. Peut-on supposer que le support de Web SQL Database continuera d'exister, même si IndexedDB devient le standard ?

(Une remarque sur CouchDB : le considérez-vous également comme une alternative ?)

26voto

Will Hartung Points 57465

Eh bien, comme pour tout ce qui concerne l'informatique, le jeu est l'"abstraction".

Si vous pouvez proposer une couche adéquate qui fonctionne à la fois sur un magasin SQL et sur un magasin clé/valeur, vous êtes idéalement isolé du problème et pouvez prendre en charge la mise en œuvre appropriée sur le navigateur particulier. Si votre modèle de données et vos modèles d'accès ne correspondent pas au plus petit dénominateur commun (c'est-à-dire un magasin clé/valeur), votre problème est pratiquement résolu.

Si vous pouvez utiliser l'un ou l'autre magasin, travaillez sur une couche d'accès décente et abordez le problème dans cette direction.

Attention, ce n'est pas parce que vous disposez d'un magasin k/v en arrière-plan que vous devez modéliser vos données comme un modèle k/v uniquement. En fait, une base de données n'est rien d'autre qu'un magasin k/v en arrière-plan. Si vous n'avez pas une quantité de données démesurée, vous pouvez faire beaucoup de choses. Avec une grande quantité de données, les obstacles que vous devez franchir peuvent vous coûter des performances que vous ne verrez peut-être pas avec une quantité de données plus petite. Tout dépend.

14voto

codelark Points 7168

Étant donné que seul WebSQL prend en charge les trois exigences que vous avez énumérées, votre choix ne devrait-il pas être simple ? Vous n'avez aucune idée de la feuille de route du développement de Safari ou d'Android, alors utilisez ce dont vous disposez.

4 votes

Oui, le problème réside dans le risque que je vais prendre. WebSQL sera-t-il abandonné un jour ? Est-ce une question de temps avant qu'il ne soit abandonné, ou puis-je supposer qu'il sera toujours supporté, même s'il n'est pas en développement actif ? Y a-t-il des informations que je ne prends pas en compte et qui me permettraient de faire un choix plus éclairé ? Merci.

3 votes

Il n'y a pas vraiment eu de plans concrets pour le support à long terme de Web SQL ou d'IndexedDB. Si vous voulez vraiment limiter les risques, vous pouvez toujours contourner les alternatives SQL et utiliser une bibliothèque de sérialisation JSON pour stocker des éléments dans le localStorage ou le sessionStorage HTML5.

2 votes

Je viens de découvrir que webSQL (et localStorage) n'est plus persistant dans iOS 5.0.1. L'emplacement où sont stockées les données webSQL est désormais régulièrement nettoyé par l'OS. Si vous utilisez Phonegap/Cordova, un plugin de contournement est en cours de développement. issues.apache.org/jira/browse/CB-330

8voto

Tino Points 529

Je vous recommande de aller pour IndexDB parce qu'il y a un Polyfill d'IndexDB disponible.

Tous les navigateurs supportant WebSQL peuvent prendre en charge la fonction API d'IndexDB de cette façon. L'inverse serait très difficile à mettre en œuvre, donc si vous voulez atteindre tous les navigateurs qui connaissent une API de base de données, IndexDB est le meilleur choix aujourd'hui.


Note : Même si cette question est ancienne, elle est toujours pertinente. Je pense donc que les réponses à cette question méritent une mise à jour. Et désolé pour la solution du lien uniquement, j'ai donc ajouté uniquement des liens vers des destinations habituellement durables : W3C et GitHub

6voto

fish2000 Points 1523

Vos besoins en matière de base de données vont-ils bien au-delà des magasins clés/valeurs ? Si ce n'est pas le cas, j'ai trouvé un certain nombre de paquets javascript pour une abstraction de base de données locale basée sur le navigateur. L'un de ces paquets est jStore :

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

Je l'ai récemment utilisé pour ajouter un stockage local de clés/valeurs. Il est bien documenté et le temps d'intégration a été négligeable - il prend en charge un ensemble de backends de stockage, y compris le stockage local flash, via son API.

CouchDB est une excellente solution - pour un problème qui ne correspond pas tout à fait au vôtre. Consultez couchone mobile . Il n'est pas destiné aux applications strictement "web", mais il peut fournir une base de données avec laquelle vous pouvez travailler, si vous disposez d'une certaine souplesse dans les spécifications.

6voto

Kyaw Tun Points 3878

Avec votre exigence de Safari sur iOS, il n'y a pas d'autre alternative que WebSQL. WebSQL est supporté par d'autres navigateurs mobiles comme Opera et Blackberry. Je ne pense pas qu'ils vont supprimer le support de WebSQL même s'ils ont IndexedDB. D'une certaine manière, ils sont complémentaires.

D'autre part, dans la guerre du stockage des navigateurs, IndexedDB a gagné pour de bon. IE et FF ne disposeront que d'IndexedDB. Un fait ironique est que FF implémente IndexedDB au-dessus de Sqlite.

Ce que je voudrais dire, c'est que IndexedDB est plus qu'un simple magasin de clés et de valeurs. Elle possède des index et des transactions. Ces deux éléments à eux seuls fournissent presque toutes les fonctionnalités des requêtes SQL, y compris la jointure, la conditionnalité et le tri. Ce n'est pas évident au début à cause de son API asynchrone.

Les performances d'IndexedDB sont meilleures que celles de WebSQL. Il est plus sûr. Il est plus flexible pour les cas d'utilisation de javascript. Enfin, il est plus facile à utiliser.

Pour illustrer le cas, je vais utiliser un pseudo code tiré de ma bibliothèque mais vous pouvez utiliser directement l'API IndexedDB :

Le magasin "people" possède un champ d'indexation "name" et un champ d'indexation de liste "hobby". En JSON,

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

Récupérer le nom des "personnes" dont le hobby est le "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);
  });
});

Ce qui est intéressant dans ce code, c'est qu'il n'y a pas de sérialisation. Il est donc très rapide.

L'exemple suivant illustre une requête de graphique d'amitié. friendship le magasin d'objets n'a qu'un seul champ indexé répertorié friend_list . Il utilise la clé du magasin d'objets des personnes comme clé primaire hors ligne. people Le magasin d'objets possède de nombreux attributs, parmi lesquels location champ. La requête est de trouver une liste d'amis qui connaissent me y other_guy et situé à "Singapour".

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

Encore une fois, cette requête jointe n'est qu'un balayage de clés et est donc très rapide. Par défaut scan utilisent un algorithme de fusion triée pour trouver les clés correspondantes, mais ici, il s'agit d'un algorithme de jointure naïf en boucle imbriquée. La jonction de tables est donc possible, mais vous devez coder l'algorithme de jonction. Mais les algorithmes plus récents comme la fusion en zigzag sont plus rapides qu'avec Sqlite car toutes les entrées sont triées, les curseurs peuvent également avancer et, plus important encore, le processus de jointure peut exploiter des connaissances externes qui ne se trouvent pas dans la base de données. Avec SQL, l'opération de jointure est opaque.

En outre, IndexedDB peut être utilisé pour des techniques comme le streaming et le traitement map/reduce.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X