起初我决定使用localStorage，花了两天后，我意识到它很奇怪，因此放弃了它。今天整整一天，实际上是在Google Chrome中获取输出，它不在android应用程序的WebView中运行。无论如何，我注意到PhoneGap仍然使用Web SQL，而android的浏览器也支持它。
为什么首先弃用Web SQL？现在使用Web SQL对我来说是一个好主意吗？
#1 楼
简短版：不赞成使用Web SQL，因为标准确实非常重要，而将Web SQL转换为适当的标准将非常困难。它的标准基本上是“执行SQLite的操作”。这还不够好；真正的标准需要自成体系，以定义接口和极端情况以及异常本身，而不是指向现有的实现（尤其是像SQLite这样的第三方实现）。否则，您将冒着接受某个特定实现的怪癖并将其纳入标准的风险。根据我的阅读，W3C倾向于建议标准的多个独立实现，以确保这一点的实现。由于Web SQL与SQLite紧密相连，因此这种情况不会发生。Mozilla的博客提供了有关其推理的更多详细信息，尤其是不支持Web SQL的推理。显然，它们是弃用Web SQL的主要声音之一。
您现在应该使用Web SQL吗？我不希望当前支持它的供应商（例如Google和Apple）会在短期内删除它，但是IE和Firefox不会添加它，并且由于它已被弃用，为什么还要投资呢？ （例如，不建议使用具有Google Developer Relations的Ido Green。）
评论
Ido的那篇文章是非常基础的，甚至都没有弄清楚为什么一个人应该使用另一个。事实是，noSQL数据库在设计时就考虑到了大容量，而这不适用于在用户单台计算机上运行的数据库。您可能会获得一些与大数据有关的优势，但会丢失JOIN之类的东西。如果必须使用indexedDb（并且我确实在appengine中使用noSQL数据存储库），则无法开发开源的“ Trello Plus” chrome扩展程序，因此我选择了Web sql。
–齐格·曼德尔（Zig Mandel）
2014年5月24日6:08
因为Google GMail MS-Outlook竞争对手随后可以进行全文搜索，并且因为只有一个SQLite实现（MS）时不可能“拥抱，扩展，消除”，并且因为Jonas Sicking（Mozilla）不喜欢SQL。带有复杂接口的键值存储当然要好得多（又叫hyphe），特别是因为每个JavaScript对象已经是一个关联数组。让我们面对现实，对于那些不（想要）理解SQL（也就是“用户不需要SQL”）的人来说，数据规范化，参照完整性和基于集合的操作确实令人反感。
–四进制
15年7月17日在11:53
具有讽刺意味的是，如果这正是您想要做的（并且不需要PRAGMA），则WebSQL非常适合与SQLite进行交互。
–迈克尔
16年5月11日在0:49
因此mozilla杀死了一个在许多情况下非常有用的项目和技术，因为那里的某些人不喜欢它，而人们却为之辩护。为什么？他们可以同时实现IndexedDB和WebSQL
–yoyo_fun
17年2月13日在6:27
Safari 13现在已经删除了早期版本对WebSQL的支持。
–雷铸
19-10-8在19:50
#2 楼
乔什·凯利（Josh Kelley）的答案是迄今为止我发现有关停止标准工作的原因的最佳答案。就是说，我认为关于用户群还需要考虑其他角度。技术有效”）...我相信（正如Ido Green的评论中的vi4m所述）：使用这项技术。没有浏览器供应商要求删除此技术，也没有计划删除它。开发人员是网络的声音。我们仍然可以使用它，也许Mozilla会改变主意;-)
我还要添加另一种合乎逻辑的方法：如果您是针对移动环境而开发的。更多手？答案：iOS和Android ...
如果两者都支持webSQL，而您的目标是MASSIVE MOBILE，那就去吧！首先是MOST，然后（一旦成功）重新创建工作，以减少剩余的工作（如果您真的想实现目标，或者被要求这样做）。最后，并非总是成功的人会标志着道路吗？技术巨头之间的新冷战甚至不应该存在。
我相信规范是可以保留的（越长越好，对客户导向的性能越好）。具有讽刺意味的是，“规范专家”的工作是生成新的规范（有时不需要，因此他可以做更多的事情），同样，程序员的工作有时专注于更改和重写已经起作用的东西，而不是为新问题做解决方案和新趋势。
对我而言，客户端数据库只是在服务器和客户端之间进行并行处理，因此我们可以轻松地创建，存储，上传和下载数据。在这种方法下，具有相同的语言和结构（至少对我们来说是LAMP开源开发人员）是直截了当和逻辑的。好的方法，但是在某种程度上，它对我来说类似于开发需要安装NEEDS的软件的需求（即使核心解决方案可以保留在云中）。在一个倾向于保持联系的世界中，这听起来像是A）控制和拥有的问题，或者B）专注于为客户端开发怪物……但是对于这种需求，存在应用程序（在移动世界中）和软件（在PC世界中）。
我相信Webapp的目标应该主要放在扩展Web上，而不管设备是什么。
评论
请注意，最新的Firefox版本和IE根本不支持WebSQL。
–ocodo
15 Mar 25 '15在0:00
据我所知，他们从未支持过WebSQL。您可以在此处进行检查：[link] caniuse.com/#feat=sql-storage。唯一令我惊讶的是Opera Mini，他们正以这种方式失去市场。无论如何，对我来说，作为开发人员，唯一重要的是适用于WebApp的iOS和Android，以及同样相信WebKit的WebKit，它们都是系统的引擎。
– DavidTaubmann
15年4月8日在19:33
但是，所有商业浏览器都没有采用客户端存储标准：html5rocks.com/en/features/storage
– DavidTaubmann
2015年4月8日在20:39
Safari 13现在已经删除了早期版本对WebSQL的支持。因此，“没有浏览器供应商要求删除该技术，也没有计划删除它”不再成立。
–雷铸
19年10月8日在19:51
@Thunderforge感谢您提供信息！真的很高兴知道！三思而后行，我不知道这对开发人员是有害还是对iOS不利，因为该工具已经存在多年了，对我们来说是完整且有用的。我们可能建议我们的用户不要使用或购买更多Mac或iOS设备，除非有人支付将项目重新编程为indexedDB的费用。
– DavidTaubmann
19-10-8在20:07
#3 楼
现实情况是，参与各方在标准制定方向上陷入了僵局。简而言之，没有人可以达成共识。W3C网站对此进行了解释。相同的SQL后端（Sqlite），但是我们需要多个独立的实现，才能沿着标准化路径进行操作。
WSC站点
评论
对我而言，这某种程度上意味着他们同意在该途径上没有其他标准化的方法……之所以能很好地工作，是因为它将标准的途径与他们应该/可能不应该对其进行标准化的现有第三方技术相连接。
– DavidTaubmann
15年4月8日在19:54
对我来说，这听起来像：他们不同意这一点，因为它不允许使用供应商特定的功能（拥抱，扩展，淘汰？）。
–四进制
15年7月17日在11:30
我相信这是某种特定于供应商的偏好，下一句话表明研究正在进行中。因此，我不确定各方是否对当前状态感到满意……“ Web应用程序工作组继续致力于其他两个与存储相关的规范：Web存储和索引数据库API。”
–htm11h
16年2月8日在13:42
@Quandary实际上相反。只有一个供应商，这是一个问题，因为该供应商的错误已成为标准的一部分。
–user253751
20-11-06在14:07
@ user253751：问题在于供应商无法决定统一的标准。因此，最终发生的事情是，两个供应商的错误成为了不存在的标准的一部分，而且情况更糟。 IndexedDb是一个很好的例子。好的，我的意思是不好。
–四进制
20年11月6日14:39
#4 楼
仅仅发布一下就可以让您知道，只是因为在所有糟糕的浏览器中都已弃用/删除/不支持WebSQL，所以不需要使用IndexedDb。
您可以通过WebAssembly使用SQLite或通过sql.js使用JS-Polyfill。
也就是说，
SQLite已编译到WebAssembly（对于现代浏览器）**
和JavaScript（对于顽固的浏览器）。
（通过emscripten）。太酷了吧？
现在，由于IE / OldEdge和Firefox已经基本消失，这为我们提供了操作Safari的空间，这意味着WebSQL的未来再好不过，即使Google愿意从Chrome / Chromium中删除它；-)
此外，这还使我们能够自己选择所需的SQLite版本。
实际上，这比WebSQL更好。
注意：您需要将数据存储在IndexedDb中以保持持久性。
https://github.com/sql-js/sql.jshttps://github.com/kripken/sql.jshttps:/ /github.com/Philzen/WebSQL-Polyfill
演示：https：//sql.js.org/examples/GUI/index.html
评论
您对localStorage有什么奇怪的发现？它只是一个键/值对存储。我很好奇您不喜欢它以及遇到的问题类型。我正在项目中使用它，想知道您遇到的案例问题。@oligofren，如果您在Web SQL中使用的不仅仅是简单的，简单的SQL，就无法将其完全转换为localStorage等。
但是，省去了创建抽象层的麻烦（我做到了），现在仅使用YDN-DB dev.yathit.com/ydn-db/index.html。它将使用适用于该设备的最佳技术。
您始终在使用某种抽象层。那是编程，以及如何实现一致的行为，而与浏览器中的实现错误无关。虚拟js调用每秒超过5000个，因此，除非YDN-DB的作者做过一些荒谬的愚蠢的事情，否则您不应在接近100ms的位置受到任何性能影响。在本地不支持IndexedDB的平台上，对于1：1运维，更像1ms。目前，仅旧版本。当前所有的浏览器都支持IndexedDB。不建议使用WebSQL。并在“优化”技术之前尝试一些简单的配置：-)
@oligofren，您错过了我的评论的重点。我不是在谈论一个函数调用另一个函数的开销，反之亦然。我的意思是，当您使用数据库抽象层时，您将自己限制为可以使用的SQL查询模式的子集，而不会遭受性能损失。您无法进行调优，因为该库会自动为您完成调优，而并非总是正确无误。除非只存储1行数据，否则不会是1ms。