Pourquoi la base de données Web SQL est-elle déconseillée?

Je fais une application hybride Android.

Au début, j’ai décidé d’utiliser localStorage. Après avoir passé deux jours, j’ai réalisé que c’était très étrange et j’ai donc laissé tomber.

Ensuite, j'ai pris indexedDB, après avoir passé la journée entière à obtenir le résultat dans Google Chrome, il ne s'exécute pas dans une vue Web de l'application Android.

Et je n'ai jamais utilisé de base de données Web SQL, car elle était obsolète. Quoi qu'il en soit, il m'est apparu que PhoneGap utilisait toujours Web SQL et que les navigateurs Android le supportaient.

Pourquoi Web SQL est-il déconseillé en premier lieu? Et est-ce que ce sera une bonne idée pour moi d’utiliser Web SQL maintenant?

html5 sqlite deprecation local-storage indexeddb moucheron
la source

Qu'avez-vous trouvé étrange à propos de Local Storage? C'est juste un magasin de paires clé / valeur. Je suis curieux de savoir ce qui vous a déplu et le type de problèmes que vous avez rencontrés. Je l'utilise dans un projet et j'aimerais connaître le problème que vous avez rencontré.

jmq

@oligofren, si vous utilisez plus que du simple-cerveau-mort-simple SQL dans le Web SQL, vous ne pouvez pas le traduire exactement en localStorage, etc.

Pacerier

Mais évitez les tracas liés à la création d'une couche d'abstraction (ce que j'ai fait), et utilisez simplement YDN-DB pour l'instant dev.yathit.com/ydn-db/index.html . Il utilisera la meilleure technologie disponible pour cet appareil.

oligofren

Vous utilisez toujours une couche d'abstraction. C’est la programmation et la manière d’obtenir un comportement cohérent, quels que soient les problèmes d’implémentation du navigateur. Les appels factices js dépassent les 5000 par ms. Par conséquent, à moins que l'auteur de YDN-DB n'ait accompli quelque chose de ridiculement stupide, vous ne devriez pas avoir un coup dur aux performances de l'ordre de 100 ms. Plus semblable à 1 ms, pour les opérations 1: 1, sur des plates-formes qui ne prennent pas nativement en charge IndexedDB. Ce qui, pour le moment, n'est que des versions plus anciennes. Tous les navigateurs actuels supportent IndexedDB. WebSQL est obsolète. Et essayez quelques profils simples avant d’optimiser les technologies :-)

oligofren

@oligofren, vous manquez le point de mon commentaire. Je ne parle pas des frais généraux d'une fonction appelant une autre et vice-versa. Je dis que lorsque vous utilisez une couche d'abstraction de base de données, vous vous limitez à un sous-ensemble de modèles de requête SQL que vous pouvez utiliser sans subir de pénalités de performances. Vous ne pouvez faire aucun réglage car la bibliothèque le fait pour vous automatiquement et ne le comprend pas toujours correctement. Cela ne va pas être 1ms sauf si vous ne stockez qu'une seule ligne de données.

Pacerier

Réponses:

100

Version courte: Web SQL était obsolète car les normes étaient très importantes et il aurait été extrêmement difficile de convertir Web SQL en normes appropriées.

Comme les implémentations existantes de Web SQL sont essentiellement des enveloppes autour de SQLite, toute tentative de définition d’un standard correspond essentiellement à "faire ce que SQLite fait". Ce n'est pas assez bon. une vraie norme doit être autonome: définir l'interface et les cas et exceptions eux-mêmes au lieu de pointer vers une implémentation existante (en particulier une implémentation tierce telle que SQLite). Sinon, vous courez le risque de prendre les défauts d'une implémentation particulière et de les définir comme norme. D'après ce que j'ai lu, le W3C préfère plusieurs implémentations indépendantes des normes proposées afin de garantir que cela se produise. Puisque le Web SQL était tellement lié à SQLite, cela ne se produirait tout simplement pas.

Le blog de Mozilla donne plus de détails sur leur raisonnement, notamment en ce qui concerne la non-prise en charge de Web SQL. apparemment, ils ont été l’une des voix les plus importantes dans la dépréciation de Web SQL.

Devez-vous aller avec Web SQL maintenant? Je ne m'attends pas à ce que les fournisseurs qui le prennent actuellement en charge (tels que Google et Apple) le lâchent de sitôt, mais IE et Firefox ne l'ajouteront pas. Et comme il est obsolète, pourquoi investir dans ce produit? (Par exemple, Ido Green , avec Google Developer Relations, ne recommande pas de l'utiliser.)

Josh Kelley
la source

Cet article d'Ido est super basique et ne raconte même pas pourquoi on devrait utiliser l'un ou l'autre. le fait est que les bases de données noSQL ont été conçues pour une taille importante, et que cela ne s'applique tout simplement pas à une base de données s'exécutant sur un seul ordinateur. Vous pouvez obtenir certains avantages liés au Big Data, mais vous perdez des éléments tels que les JOIN. Il n’ya aucun moyen que j’aurais pu développer mon extension open source chromée "Plus for Trello" si je devais utiliser indexedDb (et j’utilise aucun magasin de données noSQL dans appengine), alors j’ai opté pour Web SQL.

Zig Mandel

Parce que le concurrent Google GMail MS-Outlook pouvait alors effectuer une recherche en texte intégral et parce qu’il n’était pas possible d’embrasser, d’extraire ou d’exterminer, il n’existait aucune implémentation SQLite (MS) et Jonas Sicking (Mozilla) n’aimait pas SQL. Les magasins de valeurs de clés avec une interface trop compliquée sont bien mieux que cela (alias in hyphe), d’autant plus que chaque objet JavaScript est déjà un tableau associatif. Et, avouons-le, la normalisation des données, l'intégrité référentielle et les opérations basées sur les ensembles sont vraiment révoltantes pour quelqu'un qui ne comprend pas le code SQL, autrement dit "Les utilisateurs ne veulent pas du code SQL".

Quandary

Ironiquement, WebSQL est parfait pour interagir avec SQLite si c'est exactement ce que vous voulez faire (sans avoir besoin de PRAGMA).

Michael

mozilla a donc tué un projet et une technologie extrêmement utile dans de nombreuses situations, car certaines personnes ne l’aimaient pas et les défendaient. Pourquoi? ils pourraient implémenter BOTH IndexedDB AND WebSQL

yoyo_fun 13/02/2017

Safari 13 a maintenant supprimé la prise en charge de WebSQL par rapport aux versions précédentes.

Thunderforge

La réponse de Josh Kelley est pour l’instant la MEILLEURE réponse que j’ai jamais trouvée concernant la raison de l’interruption du travail habituel. Cela dit, je pense qu'il y a une perspective supplémentaire à considérer en ce qui concerne la base d'utilisateurs.

Même si je ne suis pas d’accord sur l’approche d’Ido Green en la matière ("C’est une recommandation pour les développeurs Web de ne plus utiliser la technologie de manière aussi efficace") ...

Je crois (comme le dit vi4m dans les commentaires de l'article d'Ido Green):

Nous (développeurs) pouvons toujours utiliser cette technologie. Aucun fournisseur de navigateur n'a demandé la suppression de cette technologie ni planifié de la supprimer. Les développeurs sont la voix du Web. Nous pouvons simplement continuer à l'utiliser, peut-être que Mozilla changera d'avis ;-)

Et j’ajouterais une autre approche logique: si vous développez pour une ambiance mobile ... Quels sont les ambiants entre plusieurs mains? Réponse: iOS et Android ... Donc, si les deux prennent en charge webSQL et que votre cible est MASSIVE MOBILE, allez-y!

Pensez comme les grandes applications l'ont presque toujours fait au début, obtenez le MOST en premier, puis (une fois le succès obtenu), recréez le travail pour obtenir le reste (si vous voulez vraiment les réaliser ou si vous êtes invité à le faire). Enfin, pas toujours le succès qui marque le chemin?

Après avoir lu l'article de Nolan Lawson (dans lequel il est clair qu'il avait l'intention de donner une chance à son invention), je pense que cette affaire est devenue une nouvelle guerre froide entre des géants de la technologie qui ne devrait même pas exister. Je crois que les spécifications sont faites pour rester (plus longtemps et aussi intacte que possible, le meilleur pour la performance orientée client). Ironiquement, le travail des "spécialistes" consiste à générer de NOUVELLES spécifications (parfois là où il n'y en a pas besoin, il peut donc avoir autre chose à faire). De même, les emplois de programmeurs sont parfois axés sur la modification et la réécriture de ce qui fonctionne déjà au lieu de proposer des solutions à de nouveaux problèmes. et nouvelles tendances.

Pour moi, les bases de données côté client consistaient simplement à faire des parallèles (entre les côtés serveur et client) afin que nous puissions créer, stocker, télécharger et télécharger facilement des données. Sous cette approche, avoir les mêmes langages et les mêmes structures (du moins pour nous, les développeurs open source LAMP) est simple et logique.

Je pense que l'intention de IndexedDB de constituer une alternative offrant des possibilités plus larges et plus récentes est une bonne approche, mais me rapproche de la nécessité de développer un logiciel que NEEDS doit être installé (même lorsque la solution principale peut rester sur le cloud). Dans un monde qui a tendance à rester connecté, cela ressemble à A) une question de contrôle et de possession ou B) de se concentrer sur le développement de monstres pour le côté client ... mais pour ce type de besoins, il existe des applications (dans le monde mobile) et des logiciels. (dans le monde PC). Je crois que l'objectif des Webapps devrait rester principalement sur l'extension du Web, peu importe l'appareil.

Je crois qu'une belle infographie pourrait sortir de cette approche.

DavidTaubmann
la source

Veuillez noter que les versions récentes de Firefox et IE ne supportent pas du tout WebSQL.

dimanche

Autant que je sache, ils n'ont jamais supporté WebSQL. Vous pouvez vérifier cela ici: [link] caniuse.com/#feat=sql-storage . Le seul qui me surprend est Opera Mini, ils perdent le marché de cette façon. Quoi qu'il en soit, pour moi en tant que développeur, les seuls qui comptent sont iOS et Android pour WebApps, et même WebKit qui, à mon avis, est le moteur des systèmes des deux.

DavidTaubmann

Néanmoins, aucune norme de stockage côté client n'a été adoptée par tous les navigateurs commerciaux: html5rocks.com/fr/features/storage

DavidTaubmann

Safari 13 a maintenant supprimé la prise en charge de WebSQL par rapport aux versions précédentes. Donc, "Aucun fournisseur de navigateur n'a demandé la suppression de cette technologie, ni l'intention de la supprimer" n'est plus vrai.

Thunderforge

@Thunderforge Merci pour l'information! Vraiment bon à savoir! En réfléchissant un peu en avant, je ne sais pas si cela va être mauvais pour les développeurs ou pour iOS, car cet outil est complet et utile pour nous depuis tant d'années. Nous pourrions recommander à nos utilisateurs de ne plus utiliser ou acheter d’appareils Mac ou iOS, à moins que quelqu'un ne paie les coûts de reprogrammation des projets sur indexedDB.

DavidTaubmann

La réalité est que les parties contributrices se sont retrouvées dans une impasse sur l'orientation de la norme. En bref, personne ne pouvait être d'accord.

Le site du W3C explique cela.

La spécification a abouti à une impasse: tous les développeurs intéressés ont utilisé le même moteur SQL (Sqlite), mais nous avons besoin de plusieurs implémentations indépendantes pour continuer sur la voie de la normalisation.

Site de la CSM

htm11h
la source

Pour moi, cela signifie en quelque sorte qu'ils s'entendent pour dire qu'il n'y a rien d'autre à normaliser dans cette voie ... Cela fonctionne très bien car cela connecte la voie de la norme à une technologie tierce existante qui ne devrait pas / ne pourrait pas être normalisée par eux.

DavidTaubmann

Pour moi, cela ressemble à ceci: ils étaient en désaccord à ce sujet, car il ne permet pas de fonctionnalités spécifiques au fournisseur (embrasser, étendre, exterminer?).

Quandary

Je crois que c'est une sorte de préférence spécifique du vendeur, la phrase suivante indique que la recherche se poursuit. Je ne suis donc pas sûr que toutes les parties soient satisfaites de l'état actuel ... "Le groupe de travail sur les applications Web poursuit ses travaux sur deux autres spécifications liées au stockage: le stockage Web et l'API de base de données indexée."

htm11h