Por que o banco de dados Web SQL está obsoleto?

Estou fazendo um aplicativo híbrido para Android.

No começo, eu decidi usar o localStorage, depois de passar 2 dias, percebi que era muito estranho e o deixei cair.

Então, peguei o indexedDB, depois de passar o dia inteiro de hoje e realmente obter a saída no Google Chrome, ele não está sendo executado em um WebView do aplicativo Android.

E nunca usei o banco de dados Web SQL porque estava obsoleto. De qualquer forma, percebi que o PhoneGap ainda usa o Web SQL e os navegadores do Android o suportam.

Por que o Web SQL foi preterido em primeiro lugar? E será uma boa ideia eu usar o Web SQL agora?

html5 sqlite deprecation local-storage indexeddb mosquito
fonte

O que você achou estranho no localStorage? É apenas uma loja de pares chave / valor. Estou curioso para saber o que você não gostou e o tipo de problemas que encontrou. Estou usando-o em um projeto e gostaria de saber qual foi o problema do seu caso.

precisa saber é o seguinte

@oligofren, Se você estiver usando SQL mais-que-just-cérebro-dead-simples no SQL web, você pode não exatamente traduzir isso para localStorage e etc.

Pacerier

Mas poupe o trabalho de criar uma camada de abstração (como eu fiz) e use o YDN-DB agora dev.yathit.com/ydn-db/index.html . Ele usará a melhor tecnologia disponível para esse dispositivo.

precisa

Você está sempre usando uma camada de abstração de algum tipo. Isso é programação e como você consegue um comportamento consistente, independentemente dos erros de implementação no navegador. As chamadas fictícias js excedem 5000 por ms, portanto, a menos que o autor do YDN-DB tenha feito algo ridiculamente estúpido, você não deve obter um desempenho atingido em nada próximo da ordem de 100ms. Mais como 1ms, para operações 1: 1, em plataformas que não oferecem suporte nativo ao IndexedDB. Que, no momento, são apenas versões mais antigas. Todos os navegadores atuais oferecem suporte ao IndexedDB. O WebSQL está obsoleto. E experimentar alguns perfis simples antes de "otimizar" longe :-) tecnologia

oligofren

@ oligofren, você está perdendo o ponto do meu comentário. Não estou falando da sobrecarga de uma função que chama outra e vice-versa. Estou dizendo que quando você usa uma camada de abstração de banco de dados, está se limitando a um subconjunto de padrões de consulta SQL que você pode usar sem sofrer penalidades de desempenho. Você não pode fazer o ajuste porque a biblioteca faz isso automaticamente e nem sempre o corrige. Não será de 1 ms, a menos que você armazene apenas 1 linha de dados.

Pacerier

Respostas:

Versão curta: o Web SQL foi descontinuado porque os padrões são realmente importantes e transformar o Web SQL em um padrão adequado teria sido proibitivamente difícil.

Como as implementações existentes do Web SQL são basicamente invólucros em torno do SQLite, qualquer tentativa de definir um padrão era basicamente "fazer o que o SQLite faz". Isso não é bom o suficiente; um verdadeiro padrão precisa ser independente, para definir a interface, os casos de canto e as exceções em si, em vez de apontar para uma implementação existente (especialmente uma implementação de terceiros como SQLite). Caso contrário, você corre o risco de pegar as peculiaridades de uma implementação específica e consagrá-las como padrão. Pelo que li, o W3C prefere várias implementações independentes dos padrões propostos para ajudar a garantir que isso aconteça; como o Web SQL estava tão ligado ao SQLite, isso simplesmente não iria acontecer.

O blog da Mozilla fornece mais detalhes sobre o raciocínio, em particular por não oferecer suporte ao Web SQL; aparentemente, eles foram uma das principais vozes para tornar o Web SQL obsoleto.

Você deve ir com o Web SQL agora? Não espero que os fornecedores que atualmente o suportam (como Google e Apple) o abandonem tão cedo, mas o IE e o Firefox não o adicionarão e, como está obsoleto, por que investir nele? (Por exemplo, Ido Green , no Google Developer Relations, não recomenda o uso.)

Josh Kelley
fonte

Esse post do Ido é super básico e nem sequer mostra a razão pela qual um deve ser usado. o fato é que os bancos de dados noSQL foram projetados com grande tamanho em mente, e isso simplesmente não se aplica a um banco de dados em execução no computador de um usuário. Você pode obter algumas vantagens relevantes para o big data, mas perde itens como JOINs. Não há como eu ter desenvolvido minha extensão de cromo de código aberto "Plus for Trello" se eu tivesse que usar o indexedDb (e eu uso o datastore noSQL no appengine), então fui para o sql da web.

Zig Mandel

Como o concorrente do MS-Outlook do Google GMail poderia fazer pesquisa de texto completo e porque "abraçar, estender, exterminar" não é possível quando há apenas uma implementação SQLite (MS) e porque Jonas Sicking (Mozilla) não gosta de SQL. Os armazenamentos de valores-chave com uma interface complicada são obviamente muito melhores (também conhecidos como hyphe), especialmente porque todo objeto JavaScript já é um array associativo. E, convenhamos, a normalização de dados, a integridade referencial e as operações baseadas em conjuntos são realmente revoltantes para alguém que não (deseja) entender SQL, também conhecido como "Os usuários não querem SQL".

Quandary

Ironicamente, o WebSQL é perfeito para interagir com o SQLite, se é exatamente isso que você deseja fazer (e não precisar do PRAGMA).

Michael

então o mozilla matou um projeto e uma tecnologia que era extremamente útil em muitas situações porque algumas pessoas não gostaram e as defenderam. Por quê? eles poderiam implementar os dois IndexedDB E WebSQL

yoyo_fun

O Safari 13 agora removeu o suporte ao WebSQL que as versões anteriores possuíam.

Thunderforge

A resposta de Josh Kelley é até agora a melhor resposta que eu já encontrei sobre o motivo do trabalho padrão ter sido interrompido. Dito isto, acho que há uma perspectiva adicional a considerar em relação à base de usuários.

Embora eu discorde da abordagem de Ido Green sobre o assunto ("Esta é uma recomendação para os desenvolvedores da Web não usarem a tecnologia com a mesma eficácia") ...

Eu acredito (como o vi4m afirma nos comentários do artigo de Ido Green):

Nós (desenvolvedores) ainda podemos usar essa tecnologia. Nenhum fornecedor de navegador solicitou a remoção desta tecnologia, nem planeja removê-la. Os desenvolvedores são a voz da web. Ainda podemos usá-lo, talvez o Mozilla mude de idéia ;-)

E acrescentaria outra abordagem lógica: se você está desenvolvendo para ambientes móveis ... ¿quais ambientes estão em mais mãos? Resposta: iOS e Android ... Portanto, se AMBOS suportam webSQL e seu objetivo é MASSIVE MOBILE, faça isso!

Pense que os aplicativos grandes já fizeram quase sempre no início, obtenha o MAIS PRIMEIRO e depois (depois de obter sucesso) recrie o trabalho para obter o restante restante (se você realmente deseja alcançá-los ou é solicitado). Finalmente, nem sempre o sucesso é quem marca o caminho?

Depois de ler o artigo de Nolan Lawson (no qual está clara sua intenção de dar uma chance à sua invenção), acredito que esse assunto se tornou uma nova guerra fria entre gigantes da tecnologia que nem deveria existir. Acredito que as especificações são feitas para permanecer (o mais longo e intocado possível - melhor para o desempenho orientado ao cliente). Ironicamente, o trabalho "pessoal das especificações" é gerar NOVAS especificações (às vezes onde não é necessário, para que ele possa fazer mais), e da mesma forma, os trabalhos de programadores às vezes se concentram em mudar e reescrever o que já funciona, em vez de fazer soluções para novos problemas e novas tendências.

Para mim, os bancos de dados do lado do cliente eram uma questão de simplesmente fazer paralelos (entre os lados do servidor e do cliente) para que pudéssemos criar, armazenar, fazer upload e baixar dados facilmente. Sob essa abordagem, ter as mesmas linguagens e estruturas (pelo menos para nós, desenvolvedores de código-fonte aberto do LAMP) é direto e lógico.

Acredito que a intenção do IndexedDB de ser uma alternativa com possibilidades mais amplas e mais recentes é uma abordagem sempre boa, mas de alguma forma me assemelha à necessidade de desenvolver software que PRECISA ser instalado (mesmo quando a solução principal pode permanecer na nuvem). Em um mundo que tende a permanecer conectado, soa como A) uma questão de controle e posse ou B) com foco no desenvolvimento de monstros para o lado do cliente ... mas para esse tipo de necessidade existem aplicativos (no mundo móvel) e software (no mundo dos PCs). Acredito que o objetivo do Webapps deve permanecer principalmente na extensão da Web, independentemente do dispositivo.

Acredito que um bom infográfico possa sair dessa abordagem.

DavidTaubmann
fonte

Observe que as versões recentes do Firefox e o IE não suportam WebSQL.

Ocodo 25/03

Tanto quanto eu sei, eles nunca suportaram o WebSQL. Você pode verificar isso aqui: [link] caniuse.com/#feat=sql-storage . O único que me surpreende é o Opera Mini, eles estão perdendo mercado dessa maneira. De qualquer forma, para mim, como desenvolvedor, os únicos que importam são o iOS e o Android para WebApps e o WebKit da mesma forma que acredito ser o mecanismo de sistemas de ambos.

No entanto, nenhum padrão de armazenamento do lado do cliente tem sido adotado por todos os navegadores comerciais: html5rocks.com/en/features/storage

DavidTaubmann

O Safari 13 agora removeu o suporte ao WebSQL que as versões anteriores possuíam. Portanto, "Nenhum fornecedor de navegador solicitou a remoção desta tecnologia, nem planeja removê-la" não é mais verdade.

Thunderforge

@Thunderforge Obrigado pela informação! Muito bom saber! Pensando um pouco adiante, não sei se isso será ruim para desenvolvedores ou pior para iOS, pois essa ferramenta é completa e útil para nós há tantos anos. Podemos recomendar que nossos usuários não usem ou comprem mais dispositivos Mac ou iOS, a menos que alguém pague os custos para reprogramar os projetos no DB indexado.

DavidTaubmann

A realidade é que as partes contribuintes chegaram a um impasse na direção do padrão. Em suma, ninguém poderia concordar.

O site do W3C explica isso.

A especificação atingiu um impasse: todos os implementadores interessados usaram o mesmo back-end SQL (Sqlite), mas precisamos de várias implementações independentes para prosseguir no caminho de padronização.

Site da WSC

htm11h
fonte

Para mim, isso significa que eles concordam que não há mais nada para padronizar nesse caminho ... Funciona bem do jeito que está, porque conecta o caminho do padrão a uma tecnologia de terceiros existente que não deve / deve ser padronizada por eles.

Para mim, isso soa como: Eles discordaram, porque não permite recursos específicos do fornecedor (aceitar, estender, exterminar?).

Quandary

Acredito que seja algum tipo de preferência específica do fornecedor, a próxima frase afirma que a pesquisa continua. Então, eu não estou certo de todas as partes estavam satisfeitos com o estado atual ... "O Aplicações Web Grupo de Trabalho continua trabalhando em duas outras especificações relacionadas a armazenamento: Armazenamento Web e indexado API de banco de dados."

htm11h