Почему база данных Web SQL устарела?

Я делаю гибридное приложение для Android.

Сначала я решил использовать localStorage, потратив 2 дня, я понял, что это очень странно, и поэтому бросил его.

Затем я поднял indexedDB, потратив весь сегодняшний день и фактически получив вывод в Google Chrome, он не работает внутри WebView приложения для Android.

И я никогда не использовал базу данных Web SQL вообще, потому что она устарела. Как бы то ни было, до меня дошло, что PhoneGap по-прежнему использует Web SQL, и браузеры Android поддерживают его.

Почему Web SQL вообще не рекомендуется? И будет ли для меня хорошей идеей перейти на Web SQL сейчас?

— комар
источник

Что вы нашли странного в LocalStorage? Это просто хранилище пар ключ / значение. Мне любопытно, что вам не понравилось в этом и какие проблемы вы столкнулись. Я использую его в проекте и хотел бы знать, в каком случае вы столкнулись.

— JMQ

@oligofren, если вы используете в веб-SQL более простой, чем просто умственный SQL, вы не можете точно перевести его в localStorage и т. д.

— Pacerier,

Но избавьте себя от хлопот, связанных с созданием слоя абстракции (что я и сделал), и просто сейчас используйте YDN-DB dev.yathit.com/ydn-db/index.html . Он будет использовать лучшие доступные технологии для этого устройства.

— oligofren

Вы всегда используете какой-то слой абстракции. Это программирование и то, как вы добиваетесь согласованного поведения независимо от ошибок реализации в браузере. Фальсифицированные js-вызовы превышают 5000 в мс, поэтому, если автор YDN-DB не сделал что-то смехотворно глупое, вы не должны потерять производительность где-то около 100 мс. Больше похоже на 1ms для операций 1: 1 на платформах, которые изначально не поддерживают IndexedDB. Что, на данный момент, это только старые версии. Все текущие браузеры поддерживают IndexedDB. WebSQL устарела. И попробуйте несколько простых профилировок, прежде чем «оптимизировать» технику :-)

— oligofren

@oligofren, ты упустил смысл моего комментария. Я не говорю о накладных расходах одной функции, вызывающей другую и наоборот. Я говорю, что когда вы используете слой абстракции БД, вы ограничиваете себя подмножеством шаблонов запросов SQL, которые вы можете использовать, не страдая от снижения производительности. Вы не можете выполнять настройку, потому что библиотека делает это автоматически и не всегда делает это правильно. Это не будет 1 мс, если вы не храните только 1 строку данных.

— Pacerier

Ответы:

100

Короткая версия: Web SQL устарел, потому что стандарты действительно важны, и превратить Web SQL в надлежащий стандарт было бы непосильно сложно.

Поскольку существующие реализации Web SQL по сути являются обертками вокруг SQLite, любая попытка определить его стандарт была в основном «делай то, что делает SQLite». Это не достаточно хорошо; истинный стандарт должен быть самодостаточным, чтобы определять интерфейс, а также сами случаи и исключения, а не указывать на существующую реализацию (особенно стороннюю реализацию, такую как SQLite). В противном случае вы рискуете принять причуды одной конкретной реализации и закрепить их в качестве стандарта. Из того, что я прочитал, W3C предпочитает несколько независимых реализаций предлагаемых стандартов, чтобы гарантировать, что это произойдет; поскольку Web SQL был так привязан к SQLite, этого просто не произойдет.

Блог Mozilla содержит более подробную информацию об их аргументации, в частности, о том, что он не поддерживает Web SQL; по-видимому, они были одним из главных голосов в устаревшем Web SQL.

Должны ли вы перейти с веб-SQL сейчас? Я не ожидаю, что поставщики, которые в настоящее время поддерживают его (например, Google и Apple), в ближайшее время откажутся от него, но IE и Firefox не будут его добавлять, и, поскольку он устарел, зачем инвестировать в него? (Например, Ido Green с Google Developer Relations не рекомендует его использовать.)

— Джош Келли
источник

Этот пост Ido является суперосновным и даже не затрагивает вопрос о том, почему следует использовать один или другой. Дело в том, что базы данных noSQL были разработаны с учетом большого размера, и это не относится к базе данных, работающей на одном компьютере пользователя. Вы можете получить некоторые преимущества, относящиеся к большим данным, но вы потеряете такие вещи, как JOIN. Нет никакого способа, которым я мог бы разработать свое хромовое расширение «Plus for Trello» с открытым исходным кодом, если бы мне пришлось использовать indexedDb (и я использую хранилище данных noSQL в appengine), поэтому я пошел на web sql.

— Зиг Мандель

Поскольку конкурент Google GMail MS-Outlook мог бы затем выполнять полнотекстовый поиск, а поскольку "охватывать, расширять, уничтожать" невозможно, когда существует только одна реализация SQLite (MS), а Jonas Sicking (Mozilla) не любит SQL. Хранилища значений ключей со слишком сложным интерфейсом, конечно, намного лучше (точнее, дефис), тем более что каждый объект JavaScript уже является ассоциативным массивом. И давайте посмотрим правде в глаза, нормализация данных, ссылочная целостность и операции на основе множеств действительно отвратительны для тех, кто не хочет (хочет) понимать SQL, он же «пользователи не хотят SQL».

— затруднение

по иронии судьбы, WebSQL идеально подходит для взаимодействия с SQLite, если это именно то, что вы хотите сделать (и не нуждаетесь в PRAGMA).

— Майкл

таким образом, Mozilla убила проект и технологию, которая была чрезвычайно полезна во многих ситуациях, потому что некоторым людям это не нравилось, и люди защищали их. Почему? они могли бы реализовать ОБА IndexedDB И WebSQL

— yoyo_fun

Safari 13 теперь удалил поддержку WebSQL, которая была в более ранних версиях.

— Thunderforge

Ответ Джоша Келли - пока ЛУЧШИЙ ответ, который я когда-либо встречал, о причине остановки стандартной работы. Тем не менее, я думаю, что есть дополнительная перспектива для рассмотрения относительно пользовательской базы.

Несмотря на то, что я не согласен с подходом Идо Грина к этой теме («Это рекомендация для веб-разработчиков не использовать эту технологию более эффективно») ...

Я верю (как заявляет vi4m в комментариях к статье Идо Грина):

Мы (разработчики) все еще можем использовать эту технологию. Ни один поставщик браузеров не требовал удаления этой технологии и не планировал ее удалять. Разработчики - это голос Интернета. Мы можем просто использовать его, может быть, Mozilla передумает ;-)

И я бы добавил еще один логический подход: если вы разрабатываете для мобильной среды ... ¿какие среды находятся в большем количестве рук? Ответ: iOS и Android ... Так что, если ОБА поддерживает WebSQL, и ваша цель - МАССОВАЯ МОБИЛЬНОСТЬ, сделайте это!

Подумайте, как большие приложения сделали почти всегда с самого начала, сначала получите МОСТ, а затем (после достижения успеха) воссоздайте работу, чтобы получить оставшееся меньше (если вы действительно хотите их достичь или вас об этом просят). Наконец, разве не всегда успех, кто отмечает путь?

После прочтения статьи Нолана Лоусона (в которой ясно, что он намерен дать шанс на свое изобретение), я считаю, что этот вопрос стал новой холодной войной между техническими гигантами, которой даже не должно существовать. Я считаю, что технические характеристики остаются неизменными (чем дольше и нетронутыми, насколько это возможно, тем лучше для ориентированной на клиента производительности). По иронии судьбы, работа "специалиста" состоит в том, чтобы генерировать НОВЫЕ спецификации (иногда там, где в этом нет необходимости, поэтому у него может быть что-то большее), и аналогичным образом задания программистов иногда фокусируются на изменении и переписывании того, что уже работает, вместо того, чтобы решать новые проблемы и новые тенденции.

Для меня клиентские базы данных - это просто создание параллелей (между серверной и клиентской сторонами), чтобы мы могли легко создавать, хранить, загружать и загружать данные. При таком подходе наличие одинаковых языков и структур (по крайней мере для нас, разработчиков LAMP с открытым исходным кодом) - это просто и логично.

Я считаю, что намерение IndexedDB стать альтернативой с более широкими и новыми возможностями - это всегда хороший подход, но каким-то образом он напоминает мне необходимость разработки программного обеспечения, которое НУЖНО установить (даже если основное решение может остаться в облаке). В мире, который стремится оставаться на связи, это звучит как A) вопрос контроля и владения или B) сосредоточение внимания на разработке монстров для клиентской стороны ... но для такого рода потребностей существуют приложения (в мобильном мире) и программное обеспечение (в мире ПК). Я считаю, что цель Webapps должна заключаться в основном в расширении сети независимо от устройства.

Я верю, что при таком подходе может получиться хорошая инфографика.

— DavidTaubmann
источник

Обратите внимание, что последние версии Firefox и IE не поддерживают WebSQL вообще.

— ocodo

Насколько я знаю, они никогда не поддерживали WebSQL. Вы можете проверить это здесь: [ссылка] caniuse.com/#feat=sql-storage . Единственное, что меня поражает, это Opera Mini, так они теряют рынок. В любом случае, для меня, как для разработчика, важны только iOS и Android для WebApps, а также WebKit, который, как я считаю, является системным ядром обеих систем.

— DavidTaubmann

Тем не менее, ни один из стандартов хранения на стороне клиента не был принят всеми коммерческими браузерами: html5rocks.com/en/features/storage

— DavidTaubmann

Safari 13 теперь удалил поддержку WebSQL, которая была в более ранних версиях. Так что «ни один поставщик браузеров не требовал удаления этой технологии и не планировал ее удалять» больше не соответствует действительности.

— Thunderforge

@ Thunderforge Спасибо за информацию! Действительно приятно знать! Подумав немного дальше, я не знаю, будет ли это плохо для разработчиков или хуже для iOS, так как этот инструмент был полным и полезным для нас на протяжении многих лет. Мы можем порекомендовать нашим пользователям больше не использовать и не покупать устройства Mac или iOS, если только кто-то не оплатит перепрограммирование проектов в indexedDB.

— Дэвид Таубманн

Реальность такова, что участвующие стороны зашли в тупик в направлении стандарта. Короче, никто не мог согласиться.

Сайт W3C объясняет это.

Спецификация зашла в тупик: все заинтересованные разработчики использовали один и тот же бэкэнд SQL (Sqlite), но нам нужно несколько независимых реализаций, чтобы идти по пути стандартизации.

WSC сайт

— htm11h
источник

Для меня это как-то означает, что они согласны, что на этом пути стандартизировать больше нечего ... Он работает так, как он есть, потому что он связывает путь стандарта с существующей технологией третьей стороны, которая не должна / не может быть стандартизирована ими.

— DavidTaubmann

Для меня это звучит так: они не согласны с этим, потому что он не учитывает специфичные для продавца функции (охват, расширение, уничтожение?).

— затруднение

Я полагаю, что это какое-то специфическое предпочтение поставщика, в следующем предложении говорится, что исследования продолжаются. Поэтому я не уверен, что все стороны были удовлетворены текущим состоянием ... «Рабочая группа веб-приложений продолжает работу над двумя другими спецификациями, связанными с хранением: веб-хранилищем и API индексированной базы данных.»

— htm11h