web-dev-qa-db-fra.com

Accès hors ligne - SQLite ou DB indexée?

Je suis en phase R&D de développement d'une application, avec les exigences clés suivantes:

  • HTML5 application web - qui aura également une version hybride
  • Les données des formulaires seront stockées localement, en l'absence de connexion Internet

Je ne peux pas utiliser le stockage Web en raison de limitations de quota - je compare SQLite et DB indexé .

  • SQLite semble être le mieux adapté, mais il est obsolète
  • La base de données indexée est une bonne alternative, mais il n'y a pas de prise en charge Safari - Une application hybride est censée être exécutée sur l'iPad et sur un appareil Android Android à l'avenir).

Je suis confus dans la sélection de l'API. Y a-t-il une autre alternative à SQLite ou une prise en charge de la base de données indexée attendue sur Safari?

24
Taha

Je pense que l'abandon d'IndexedDB serait une mauvaise idée, car c'est probablement le format du futur, donc Safari pourrait cesser de supporter WebSQL.

Il semble qu'il existe différentes solutions JavaScript pour combler l'écart entre les deux - en économisant celui qui est disponible sur le navigateur de l'utilisateur: Bibliothèque JavaScript pour ponter IndexedDB et WebSQL Je pense que c'est probablement votre meilleure solution.

14
Robin Winslow

Tout d'abord, celui qui a été déprécié par le W3C est WebSQL et non SQLite

IndexedDB -

  • Il est incompatible avec de nombreux types d'OS mobiles et n'est compatible qu'avec certains types de versions d'OS mobiles
  • Les développeurs ne peuvent pas utiliser SQL avec IndexedDB. Ils peuvent avec SQLite et WebSQL
  • La plupart des développeurs évitent activement d'utiliser IndexedDB autant qu'ils le peuvent

WebSQL -

  • Il est obsolète par le W3C, ce qui signifie qu'il n'est plus entretenu ou développé
  • Il nécessite un autre plugin appelé Polyfill pour permettre aux applications mobiles de fonctionner avec les systèmes d'exploitation mobiles populaires tels que Google Android et Apple iOS

SQLite -

  • Il a reçu un prix de Google
  • SQLite a son site officiel. IndexedDB et WebSQL ne
  • Sur Google, SQLite renvoie 4,3 millions de résultats. WebSQL renvoie un peu moins de 700 Ko de résultats et IndexedDB renvoie 282 Ko de résultats.

Si vous voulez un tutoriel rapide sur SQLite,

Stockage de la base de données SQLite en utilisant Android et Phonegap

15
KershawRocks

Oui, l'API IndexedDB est géniale et tous les navigateurs prendront en charge dans un avenir proche.

Je recommande définitivement ma propre solution https://bitbucket.org/ytkyaw/ydn-db c'est un wrapper très fin pour IndexedDB et je me rabat sur Sqlite pour safari.

5
Kyaw Tun

IndexedDB est très probablement la base de données prise en charge de l'avenir et il serait préférable d'y aller au lieu de WebSQL. Comme l'a souligné Raymond, il est préférable de se référer à http://www.caniuse.com pour voir le support actuel/futur dans les navigateurs de bureau et mobiles.

Selon les besoins actuels de votre solution, vous pourriez être d'accord avec l'une des nombreuses bibliothèques JavaScript disponibles qui utilisent le stockage local et fournissent une interface de requête. L'une des bibliothèques qui a bien fonctionné pour moi est Lawnchair .

3
Romin

Si vous ne voulez pas choisir entre IndexedDB ou WebSQL, vous pouvez utiliser la bibliothèque Javascript PouchDB .

Je l'utilise dans un Android Webview pour stocker des données hors ligne et cela fonctionne plutôt bien. Les données sont stockées sur une base de données locale (en utilisant IndexedDB ou WebSQL) s'il n'y a pas de connexion Internet disponible et sont synchronisées avec une base de données distante ( CouchDB base de données) lorsqu'une connexion est disponible.

PouchDB dépendra d'IndexedDB mais revenir à WebSQL si IndexedDB n'est pas pris en charge. Il existe également la possibilité d'utiliser un plugin SQLite pour Cordova/PhoneGap.

2
hadrienj

Je voulais faire une petite modification pour mettre à jour cette question, car Google nous dirige vers cette question si vous faites une recherche sur le sujet de websql, localStorage et indexedDB. L'édition a été rejetée, donc je poste comme réponse.

Comme d'autres l'ont indiqué dans leurs réponses, IndexedDB manquait un peu auparavant de support et de contenu sur le web pour sa documentation et ses spécifications.

Mais le support IndexedDB a été largement amélioré pour mobile . Il s'est tellement amélioré que le seul navigateur qui n'a pas de support ou quoi que ce soit, est Opera Mini, mais il n'a que 0,34% d'utilisation du marché .

À partir de 2015, je suggérerais à tout développeur de passer à IndexedDB, car WebSQL a été déconseillé et IE et Firefox a cessé de le prendre en charge (c'est plus de 15% de l'utilisation du marché pour ces seuls!)) Et SQLite perd rapidement de la place au profit d'IndexedDB, qui a maintenant vraiment bien sources de documentation , beaucoup . Certains officiels aussi !. Certaines sociétés informatiques sont même motivant également l'utilisation, comme IBM .

Je vais l'utiliser et je n'ai rencontré aucun problème jusqu'à présent. Safari a ajouté le support, ainsi que tous les principaux navigateurs. Fonce!

EDIT: Un addenda personnel: j'ai essayé IndexedDB. Je suis un senior de mon équipe, et la syntaxe IndexedDB est tout simplement trop compliquée et complexe pour les petits problèmes de stockage - j'ai fini par utiliser localstorage pour enregistrer quelques données JSON simples et les analyser quand j'en ai besoin. Bien mieux pour tout le monde dans mon équipe de l'obtenir (moi aussi, bien sûr!)

2
Malavos

Comme d'autres l'ont souligné, depuis que cette question a été posée, webSQL a été déconseillé , tandis que les implémentations IndexedDB existent maintenant dans tous les principaux fournisseurs de navigateurs .

Donc, pour tous ceux qui peuvent se retrouver ici face à la même décision à prendre, allez avec IndexedDB.

D'autres ici ont également laissé entendre, à juste titre, qu'il n'est pas nécessaire de faire un choix entre les deux types de bases de données. On peut simplement choisir (ou créer) une bibliothèque qui utilise la base de données disponible sur une machine cliente.

Découvrez BakedGoods si vous recherchez une telle bibliothèque. Il établit une interface uniforme qui peut être utilisée pour effectuer des opérations de stockage dans toutes les installations de stockage client natives et dans certaines installations de stockage client non natives. Il maintient également la flexibilité et les options offertes à l'utilisateur par chacun.

Avec lui, la conduite d'opérations de stockage dans n'importe quel type de base de données est prise en charge est une question de ...

... en spécifiant les options d'opération appropriées et les configurations équivalentes pour les deux types de base de données:

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

... et conduite de l'opération:

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

Son interface simple et sa prise en charge inégalée des installations de stockage se font au prix d'un manque de prise en charge pour certaines configurations spécifiques aux installations de stockage. Par exemple, il ne prend pas en charge la conduite des opérations de stockage dans les tables WebSQL avec des clés primaires à plusieurs colonnes.

Donc, si vous faites un usage intensif de ces types de fonctionnalités, vous voudrez peut-être chercher ailleurs.

Oh, et dans un souci de transparence totale, BakedGoods est maintenu par ce gars ici :).

1
Kevin

Cela peut être tard dans le jeu, mais vous pouvez regarder: SequelSphere

Il s'agit d'une base de données relationnelle 100% HTML5/JavaScript qui fonctionne sur plusieurs navigateurs et utilise le stockage local pour conserver ses données. Vous pouvez également utiliser SQL pour l'interroger. Il s'agit de son propre moteur de base de données et ne dépend pas des bases de données relationnelles intégrées (WebSQL). En tant que tel, il fonctionnera sur tous les navigateurs.

Bien qu'il ne supporte actuellement que localStorage, l'idée est de prendre en charge toutes les normes à l'avenir. Comme les navigateurs prennent en charge d'autres types de persistance, SequelSphere en profiterait. Le point positif est que vous ne codez que contre SequelSphere à l'aide de SQL standard et que vous le laissez gérer la persistance.

Néanmoins, sachez qu'il s'agit d'un nouveau produit sur le marché, ce qui présente des avantages et des inconvénients.

1
John Fowler