Perché il database Web SQL è obsoleto?

Sto realizzando un'app ibrida per Android.

Inizialmente ho deciso di utilizzare localStorage, dopo aver trascorso 2 giorni, mi sono reso conto che è molto strano e quindi l'ho lasciato cadere.

Quindi, ho rilevato IndexedDB, dopo aver trascorso l'intera giornata di oggi e effettivamente ottenere l'output in Google Chrome, non è in esecuzione all'interno di una WebView dell'app Android.

E non ho mai usato il database Web SQL perché era deprecato. Ad ogni modo, mi è venuto in mente che PhoneGap utilizza ancora Web SQL e che i browser Android lo supportano.

Perché Web SQL è stato deprecato in primo luogo? E sarà una buona idea per me andare con Web SQL ora?

— moscerino
fonte

Cosa hai trovato strano su localStorage? È solo un archivio coppia chiave / valore. Sono curioso di sapere cosa non ti è piaciuto e del tipo di problemi che hai riscontrato. Lo sto usando in un progetto e vorrei sapere il problema del caso in cui ti sei imbattuto.

— jmq

@oligofren, Se stai usando un SQL molto più di un semplice cervello nel web SQL, non puoi esattamente tradurlo in localStorage ed ecc.

— Pacerier,

Ma risparmiati la seccatura di creare un livello di astrazione (cosa che ho fatto) e usa YDN-DB per ora dev.yathit.com/ydn-db/index.html . Utilizzerà la migliore tecnologia disponibile per quel dispositivo.

— oligofren,

Stai sempre usando uno strato di astrazione di qualche tipo. Questa è la programmazione e il modo in cui si ottengono comportamenti coerenti indipendentemente dai bug di implementazione nel browser. Le chiamate js fittizie superano i 5000 al ms, quindi a meno che l'autore di YDN-DB non abbia fatto qualcosa di ridicolmente stupido, non dovresti ottenere un hit da prestazione in alcun modo vicino all'ordine di 100ms. Più come 1ms, per operazioni 1: 1, su piattaforme che non supportano IndexedDB in modo nativo. Che, al momento, sono solo versioni precedenti. Tutti i browser attuali supportano IndexedDB. WebSQL è obsoleto. E prova qualche semplice profiling prima di "ottimizzare" la tecnologia in trasferta :-)

— oligofren,

@oligofren, ti manca il punto del mio commento. Non sto parlando dell'overhead di una funzione che chiama un'altra e viceversa. Sto dicendo che quando usi un livello di astrazione db ti stai limitando a un sottoinsieme di schemi di query SQL che puoi usare senza soffrire di penalità di prestazione. Non è possibile eseguire alcuna sintonizzazione perché la libreria lo fa automaticamente per te e non sempre lo ottiene correttamente. Non sarà 1ms a meno che non memorizzi solo 1 riga di dati.

— Pacerier,

Risposte:

100

Versione breve: Web SQL è stato deprecato perché gli standard sono davvero importanti e trasformarlo in uno standard adeguato sarebbe stato proibitivo in modo proibitivo.

Poiché le implementazioni esistenti di Web SQL sono fondamentalmente avvolgenti attorno a SQLite, qualsiasi tentativo di definirne uno standard era sostanzialmente "fare ciò che fa SQLite". Questo non è abbastanza buono; un vero standard deve essere autonomo, per definire l'interfaccia, i casi angolari e le eccezioni stesse invece di indicare un'implementazione esistente (specialmente un'implementazione di terze parti come SQLite). Altrimenti, si corre il rischio di prendere le stranezze di una particolare implementazione e di sancirle come standard. Da quanto ho letto, il W3C preferisce molteplici implementazioni indipendenti degli standard proposti per garantire che ciò accada; dal momento che Web SQL era così legato a SQLite, che non sarebbe successo.

Il blog di Mozilla fornisce maggiori dettagli sul loro ragionamento, in particolare per non supportare Web SQL; apparentemente erano una delle voci più importanti nel deprecare Web SQL.

Dovresti andare con Web SQL ora? Non mi aspetto che i fornitori che attualmente lo supportano (come Google e Apple) lo lasceranno cadere presto, ma IE e Firefox non lo aggiungeranno, e poiché è deprecato, perché investire in esso? (Ad esempio, Ido Green , con Google Developer Relations, non consiglia di utilizzarlo.)

— Josh Kelley
fonte

Quel post di Ido è super semplice e non graffia nemmeno la superficie sul perché uno dovrebbe usare l'uno o l'altro. il fatto è che i database noSQL sono stati progettati pensando alle grandi dimensioni e che non si applicano solo a un database in esecuzione sul singolo computer di un utente. Potresti ottenere alcuni vantaggi rilevanti per i big data, ma perdi cose come i JOIN. Non avrei mai potuto sviluppare la mia estensione cromata open-source "Plus for Trello" se avessi dovuto usare indexedDb (e utilizzo noSQL datastore in appengine) quindi ho optato per web sql.

— Zig Mandel,

Perché il concorrente MS-Outlook di Google GMail potrebbe quindi eseguire ricerche full-text, e perché "abbracciare, estendere, sterminare" non è possibile quando esiste una sola implementazione di SQLite (MS) e perché a Jonas Sicking (Mozilla) non piace SQL. Gli archivi di valori chiave con un'interfaccia complicata sono ovviamente molto meglio (ovvero in ifem), soprattutto perché ogni oggetto JavaScript è già un array associativo. E ammettiamolo, la normalizzazione dei dati, l'integrità referenziale e le operazioni basate su set sono davvero disgustose per qualcuno che non (vuole) capire l'SQL, alias "Gli utenti non vogliono SQL".

— Quandary,

ironicamente, WebSQL è perfetto per interagire con SQLite se è esattamente quello che vuoi fare (e non hai bisogno di PRAGMA).

— Michael

così mozilla ha ucciso un progetto e una tecnologia che sono stati estremamente utili in molte situazioni perché ad alcune persone non piaceva e la gente le difende. Perché? potrebbero implementare ENTRAMBI DB indicizzati e WebSQL

— yoyo_fun il

Safari 13 ha ora rimosso il supporto per WebSQL delle versioni precedenti.

— Thunderforge

La risposta di Josh Kelley è finora la MIGLIORE risposta che abbia mai trovato sulla ragione del lavoro standard da interrompere. Detto questo, penso che ci sia un'altra prospettiva da considerare riguardo alla base di utenti.

Tuttavia, non sono d'accordo sull'approccio di Ido Green all'argomento ("Questa è una raccomandazione per gli sviluppatori web di non utilizzare più la tecnologia in modo efficace") ...

Credo (come afferma vi4m nei commenti dell'articolo di Ido Green):

Noi (sviluppatori) possiamo ancora usare questa tecnologia. Nessun fornitore di browser ha richiesto la rimozione di questa tecnologia, né prevede di rimuoverla. Gli sviluppatori sono la voce del web. Possiamo ancora usarlo, forse Mozilla cambierà idea ;-)

E aggiungerei un altro approccio logico: se stai sviluppando per l'ambiente mobile ... ¿quali ambienti sono in più mani? Risposta: iOS e Android ... Quindi, SE ENTRAMBE supporta webSQL e il tuo obiettivo è MASSIVE MOBILE, provalo!

Pensa come le grandi app hanno fatto quasi sempre all'inizio, ottieni prima la MAGGIOR PARTE, quindi (una volta raggiunto il successo) ricrea il lavoro per ottenere il rimanente meno (se vuoi davvero raggiungerle o ti viene chiesto di farlo). Infine, non è sempre successo chi segna la strada?

Dopo aver letto l'articolo di Nolan Lawson (in cui è chiara la sua intenzione di dare una possibilità alla sua invenzione) credo che questa faccenda sia diventata una nuova guerra fredda tra giganti della tecnologia che non dovrebbe nemmeno esistere. Credo che le specifiche siano fatte per rimanere (il più lungo e intatto possibile, meglio è per le prestazioni orientate al cliente). Ironia della sorte, il compito di "specifiche ragazzi" è quello di generare NUOVE specifiche (a volte dove non ce n'è bisogno, quindi può avere qualcosa in più da fare), e allo stesso modo i lavori dei programmatori a volte si concentrano sul cambiare e riscrivere ciò che già funziona invece di fare soluzioni per nuovi problemi e nuove tendenze.

Per me, i database lato client erano semplicemente una questione di parallelismi (tra lato server e lato client) in modo da poter creare, archiviare, caricare e scaricare facilmente i dati. Con questo approccio, avere gli stessi linguaggi e le stesse strutture (almeno per noi sviluppatori LAMP opensource) è semplice e logico.

Credo che l'intenzione di IndexedDB di essere un'alternativa con possibilità più ampie e più recenti sia un approccio sempre valido, ma in qualche modo assomiglia alla necessità di sviluppare software che DEVE essere installato (anche quando la soluzione di base può rimanere sul cloud). In un mondo che tende a rimanere connesso suona come A) una questione di controllo e possesso o B) focalizzata sullo sviluppo di mostri per il lato client ... ma per quel tipo di esigenze esistono App (nel mondo Mobile) e software (nel mondo dei PC). Credo che l'obiettivo di Webapps dovrebbe rimanere principalmente sull'estensione del Web, indipendentemente dal dispositivo.

Credo che una bella infografica potrebbe uscire da questo approccio.

— DavidTaubmann
fonte

Si noti che le versioni recenti di Firefox e IE non supportano affatto WebSQL.

— ottobre

Per quanto ne so non hanno mai supportato WebSQL. Puoi verificarlo qui: [link] caniuse.com/#feat=sql-storage . L'unica che mi stupisce è Opera Mini, stanno perdendo mercato in questo modo. Ad ogni modo, per me come sviluppatore gli unici che contano sono iOS e Android per WebApp e allo stesso modo WebKit che credo sia il motore di entrambi i sistemi.

— David Taubmann,

Tuttavia, nessuno standard di archiviazione sul lato client è stato adottato da tutti i browser commerciali: html5rocks.com/en/features/storage

— DavidTaubmann

Safari 13 ha ora rimosso il supporto per WebSQL delle versioni precedenti. Pertanto, "Nessun fornitore di browser ha richiesto la rimozione di questa tecnologia, né prevede di rimuoverla" non è più vero.

— Thunderforge

@Thunderforge Grazie per l'informazione! Davvero buono a sapersi! Pensando un po 'avanti, non so se questo andrà male per gli sviluppatori o peggio per iOS, poiché questo strumento è stato completo e utile per noi da così tanti anni. Potremmo raccomandare ai nostri utenti di non utilizzare o acquistare altri dispositivi Mac o iOS, a meno che qualcuno non paghi i costi per la riprogrammazione dei progetti su IndexDDB.

— David Taubmann,

La realtà è che le parti che hanno contribuito hanno raggiunto un punto morto sulla direzione dello standard. In breve, nessuno poteva essere d'accordo.

Il sito W3C spiega questo.

La specifica ha raggiunto un punto morto: tutti gli implementatori interessati hanno utilizzato lo stesso backend SQL (Sqlite), ma abbiamo bisogno di più implementazioni indipendenti per procedere lungo un percorso di standardizzazione.

Sito WSC

— htm11h
fonte

Per me, questo in qualche modo significa che sono d'accordo che non c'è nient'altro da standardizzare in quel percorso ... Funziona bene così com'è perché collega il percorso dello standard a una tecnologia di terze parti esistente che non dovrebbe / potrebbe non essere standardizzata da loro.

— David Taubmann,

Per me sembra: non sono d'accordo, perché non consente funzionalità specifiche del fornitore (abbracciare, estendere, sterminare?).

— Quandary,

Credo che sia una sorta di preferenza specifica del fornitore, la frase successiva afferma che la ricerca continua. Quindi non sono sicuro che tutte le parti siano soddisfatte dello stato attuale ... "Il gruppo di lavoro sulle applicazioni Web continua a lavorare su altre due specifiche relative allo spazio di archiviazione: Web Storage e API del database indicizzato".

— htm11h