浏览器中SQLite的历史记录

所有迹象似乎都表明，苹果最终将在今年的某个时候推出Safari7.1中的IndexedDB。这意味着Safari，对IndexedDB的最后一次抵抗，最终将对HTML5的新存储引擎的不可避免的胜利表现出仁慈的态度。

所以我认为这将是一个为Web SQL举行守夜的好时机-那么多的诽谤和误解-Ran仍然自豪地在Safari、Chrome、Opera、iOS和自2.0以来的每一个Android版本中提供。

在科技行业，我们经常太快地剔除一些最近过时的技术(Flash、SVN、Perl)，因为就像政治和宗教一样，没有什么比最近主导的时代精神更需要抹黑的了。不过，Web SQL应该得到更好的结果，所以我在这里为它付出了自己的努力。

故事的主旨是这样的：大约在2009年，原生iOS和Android应用程序开始让网络大赚一笔，W3C认识到有一个领域需要改进，那就是客户端存储。因此，苹果和谷歌修改了Web SQL数据库API，基本上承认SQLite很棒，iOS和Android上的移动开发人员都喜欢它，所以两家公司都很乐意在他们的浏览器中发布SQLite[1]。

然而，微软和(特别是)Mozilla犹豫不决，反驳说SQL语言并不是真正的标准，在WebKit中只有一个实现并不符合被认为是严肃规范所必需的“独立实现”要求。

因此，到了2010年，Web SQL被抛弃，取而代之的是IndexedDB，IndexedDB是一种文档存储，可以被认为是Web SQL的NoSQL答案。它是由甲骨文(甲骨文)的Nikunj Mehta设计的，到2014年，每个主要的浏览器，包括IE10和Android 4.4，都已经推出了IndexedDB版本，Safari预计将在今年晚些时候加入。

不过，作为一名同时使用过Web SQL和IndexedDB的普通开发人员，我无法动摇W3C在这里做出了错误选择的感觉。让我们记住Web SQL实际上给了我们什么：

浏览器中的SQLite。认真地说，一直到sqlite_master表、用于全文搜索的FTS索引和特殊类型系统。您唯一没有得到的是Pragma命令--除此之外，您还有事务、联接、二进制BLOB、正则表达式等等。

默认情况下有5MB的存储空间，根据平台的不同，最高可达50MB或更多，用户可通过不同增量的弹出窗口进行确认。

轻松连接到本地移动SQLite数据库的能力，例如使用用于Cordova/PhoneGap的SQLite插件。

一个已经在移动设备上经过战斗测试的数据库，也就是性能重要的地方。

现在我们拥有的是IndexedDB，它基本上允许您存储键/值对，其中的值是JavaScript对象文字，键可以是该对象中的一个或多个字段。它支持GET、PUT、DELETE和迭代。在Chrome中，它构建在Google的LevelDB之上，而在Firefox中，它实际上是由SQLite支持的。在IE，谁知道呢。

关于IndexedDB未能俘获开发人员芳心的文章已经写得够多了。而且API肯定不会赢得任何选美比赛：

不过，我不想老调重弹，而是想对IndexedDB背弃的承诺发表我自己的看法，并承认它在哪里取得了成功。

为了理解IndexedDB如何战胜Web SQL的背景，让我们回顾2009年。通常情况下，你需要侦察技能才能破解谋杀之谜，但幸运的是，对我们来说，W3C做的每件事都是公开的，所以整个故事都可以在互联网上公开获得。

我找到的最好的来源是2009年底的IRC日志，相应的会议记录，令人惊讶的热烈的后续帖子，以及Mozilla 2010年6月的博客帖子，起到了敲定棺材的作用[3]。

以下是我从2009年IRC日志开始重新讲述发生的事情：

好了，别开玩笑了。让我们让选手们用他们自己的话来讲述这个故事。我会尽量不发表太多的社论[2]。

我们主要与微软和甲骨文进行了很多讨论，甲骨文是Nikunj的幕后推手，我们与很多开发人员进行了交谈，得到的反馈是我们真的不想要SQL。

我们已经实现了WebDB，并且已经在Safari中发布了一段时间。

(当时，Web SQL被称为“Web DB”，而IndexedDB被称为“Web Simple DB”，或简称为“Nikunj”。)。

因此，基本上，(Mozilla的)Sking提出了挑战：用户不想要SQL，Nikunj Mehta提出的解决方案得到了Oracle、Microsoft和Mozilla这三家公司的支持。Fette(谷歌的)和Stachowiak(苹果的)怒气冲冲地回应说，他们已经推出了Web SQL。

费特在这里做出了让步。回想一下，Google很快就实现了Web SQL和IndexedDB，至少在Chrome中是这样。Android常用浏览器/WebView直到4.4版才获得IndexedDB。

Chrome实现除了提供它之外，还共享了一些但不是全部代码，网站有针对iPhone并使用它的版本，因此我们不能因为这个原因在不久的将来轻易放弃它

然而，谷歌并不想停止发布Web SQL：精灵已经从瓶子里出来了，网站也已经在使用它了。

稍后，他们将讨论LocalStorage。这是对话中一个有趣的部分：大家都知道LocalStorage是有限的，因为它只是同步的。有人建议他们可以简单地扩展LocalStorage，而不是IndexedDB，但是没有人反对这个提议。

微软的立场是，WebSimpleDB是我们希望看到的，我们不认为我们合理地能够发布一个可互操作的WebDB版本，试图实现一个可互操作的SQL版本太难了。

这里，我们得出了反对Web SQL的最好的论点之一：创建与WebKit版本匹配的单独实现太难了-Microsoft和Mozilla将不得不重写SQLite本身，以及它所有时髦的特性，或者只是将其全部包括在内，在这种情况下，它不是一个独立的实现。

对于多个可互操作的实现，当我们开始研究WebDB时，似乎不能真正称其为胎死腹中。我们喜欢Nikunj的原因是它不强制执行，但它有强大的功能，我们对WebDB的担忧是，它以SQLite为前提，我们不太确定。

建议所有发布WebDB的浏览器都是基于WebKit的建议：我们将WebDB迁移到WebKit.org，然后将其作为这个组的交付产品来扼杀。

在这一点上，几乎理所当然地认为Web SQL将从HTML5规范中删除。他们现在唯一要决定的就是是把它送给州北部的一个漂亮的农场家庭，还是把它拿到后面去拍摄。

不过，谷歌不会就此罢休。有几次，演讲者甚至被提醒，他们讨论网络存储的时间已经用完了。谷歌提出了全文搜索的理由：

苹果和谷歌已经表示有兴趣在我们使用的API中增加全文搜索。

要将其用于Gmail，我们必须能够执行全文，而我们认为在JS中无法做到这一点，所以我们希望本机代码能够做到这一点。

在一些讨论中，我们可以提供关键字/上下文，但是全文包含了更多的概念，这些概念在不同的语言中可能会变得毛骨悚然。它的表现应该与恰克指数持平。…。SPEC最初是在berkeleyDB上编写的，它无法基于键索引检索对象。有一种连接DBS的方法，但是我们添加了一种从索引中查找对象和处理索引的方法，连接的使用减少了。

因此，谷歌确实坚持他们需要对Gmail进行全文搜索，但除了苹果之外，没有人对此深信不疑。

这里有一个有趣的实验：在Chrome中打开Gmail，将你的开发工具设置为模拟移动设备，比如Nexus 4。执行搜索，然后查看资源选项卡，看看谷歌在存储方面是否做了什么有趣的事情。

如果您不确定正在查看的是什么，我将告诉您其中的秘密：这是一个虚拟表，使用SQLite的全文搜索(FTS)功能创建。请注意，根本没有使用IndexedDB。如果你使用桌面Gmail，这两个数据库都不会使用。

很明显，谷歌已经用他们的代码投票支持Web SQL，至少在移动设备上是这样。

更正：事实证明，这并不是FTS表--它只是一个带有一些奇特触发器的普通表。查询被缓存，但它们实际上并没有在客户机上运行。尽管如此，FTS在Web SQL中确实是可能的，我认为我关于Google更喜欢Web SQL而不是IndexedDB的观点仍然成立。

在Gmail示例中，如果您正在搜索收件人和发件人地址，您可能会有无数个地址，因此这可能会给系统带来很大的负担。

就世界而言，Mozilla不会实现WebDB，而我们想让Gmail与DB一起工作，还有其他人想让应用程序工作。或多或少一些细节，Web简单数据库似乎可以做到这一点。

著名的遗言。五年过去了，显然谷歌仍然认为IndexedDB还没有准备好进入黄金时间，至少在Gmail中是这样。不过，也许IndexedDBv2会挽救局面：工作草案中包含了FTS的提案，以及其他一些好东西。

在2009年的会议之后，有一个后续的电子邮件帖子，如果你想看看W3C拳头是什么样子的话，这是一个很棒的读物。奇怪的是，谷歌没有人加入这场争斗，我们只有苹果的Stachowiak站出来为Web SQL辩护：

实际上，我们这里有一点鸡和蛋的问题。Hixie之前曾说过，他愿意完全规范Web数据库使用的SQL方言。但是由于Mozilla断然拒绝实现该规范(显然不管是否指定了SQL方言)，他不想投入这项工作，因为这将是一个相对较差的时间利用。

说得好。如果Mozilla将自己的不参与称为缺乏独立的实现，那就有点不真诚了。

在面对面的会议上，Mozilla的代表表示，与他们交谈的大多数开发人员(如果不是所有的话)都表示，他们想要存储解决方案中的“任何东西”，而不是SQL。这与我们在苹果的经验相冲突，我们在苹果发布Web数据库已经将近两年了，我们已经看到许多实际的Web应用程序在使用它(主要针对iPhone)。

对我来说，这个论点是如此明显，令人心碎：SQL是一种非常新手友好的语言，而iOS(和Android)开发人员已经熟悉SQLite。那为什么要修理没坏的东西呢？

在我看来，很明显，即使我们提供Web SimpleDB作为替代方案，我们专注于移动的开发人员也会继续使用SQL数据库。首先，他们不会看到改变的令人信服的理由。其次，SimpleDB似乎需要更多的代码来执行甚至是简单的任务(比较两个规范中的并行示例)，并且似乎被设计为需要在顶层放置一个JS库才能正常工作。对于我们的移动开发人员来说，总代码大小是非常重要的。与专注于桌面的Web开发人员相比，他们似乎不太愿意发布大型JS库，并且通常使用特定于移动设备的JS库或严格删减的完整JS库版本。

这是一个很好的观点，Gmail的例子表明这一预测已经在实践中得到了证实。乔纳斯·希金回应道：

如果我们指定了特定的SQL方言，那么我们就必须实现它。该方言与SQLite兼容的可能性很小(特别是考虑到SQLite在数据类型方面使用了一种相当不寻常的SQL方言)，这可能会让我们实现自己的SQL引擎。

我绝对同意，我们不想要一个惩罚移动市场的解决方案。我认为做到这一点的方法是确保SimpleDB即使对于移动平台也是有用的。

Sick关于Mozilla在这里面临的困难是正确的，但事后看来，他对移动平台上的IndexedDB有点乐观。HTML5现在才开始在性能上赶上本地应用，而Facebook等大公司已经完全停止了对它的押注。

您会独立调用使用标准C库的多个实现吗？显然，这里需要做出判断。我意识到在这种情况下，数据库实现是问题的一个相当关键的部分。但我也认为，对您来说，推广您喜欢的解决方案会比试图找到律师理由来阻止您不喜欢的规范的发展更有成效(当后者已经实现并发布时，可能会看到更多的实现)。

Stachowiak显然对WebSQL被拒绝感到不满，他引用了他所说的“律师”原因。他接着说：

我不认为SimpleDB对移动平台毫无用处。你当然“可以”使用它。但与SQL数据库相比，它确实有三个显著的缺点：(1)它与开发人员已经(高兴地)在移动设备上使用的东西有很大的不同；(2)目标设计点是预期它主要通过顶层的JavaScript库使用，而不是直接使用(因此您必须通过网络传输更多代码)；(3)对于更复杂的查询，更多的工作必须用JavaScript完成，而不是在数据库引擎中完成(因此在低功耗CPU上的性能可能会很差)。基于这些原因，我预计很多移动开发人员会坚持使用SQL数据库，即使我们还提供了其他东西。

希克早些时候承认他是“…”经验不足，无法很好地阐述所有原因。“。因此，在斯塔科维亚克的猛烈抨击之后，另一名Mozilla员工罗伯特·奥卡拉汉(Robert O‘Callahan)赶来帮助他的同事：

>；您是否会将使用标准C库的多个实现称为独立的？显然，这里需要做出判断。

是。将查询字符串(或多或少)逐字传递到SQLite进行解析和解释的多个实现不会传递该判断调用…。我知道，但是你不同意吗？

我认为问题在于想出一个SQL定义，它可以由SQLite以外的任何东西实现(当然，也可以从头开始实现)。SQLite的一个奇怪之处在于不强制使用列类型。因此，要么该规范需要SQLite的“类型亲和性”(在这种情况下，它不能很好地与大多数其他SQL实现相匹配，并且排除了常见的性能优化)，要么它需要严格的类型检查(也许您可以通过添加CHECK约束在SQLite中实现这一点？)。但后一种方法可能与部署的内容不兼容，因此与Jonas相反，我预计该规范将*只能*在SQLite之上实现(当然，也可以从头开始)，或者可能会不自然地嵌入到所有值都是文本或变体的其他引擎中。具有替代实现经验将非常重要。

所有有效的分数。SQLite有它自己的怪癖，而Web SQL基本上是SQLite之上的一层薄薄的东西。尽管Stachowiak后来确实指出“WebKit大约有15k行代码来实现异步、检查和重写查询、导出DOMAPI、管理事务、公开结果集等。”

您是否可以轻松获取有关这些移动应用程序执行的复杂查询的知识？那会很有用的。

令苹果公司名誉扫地的是，(据我所知)从未提供过这样的数据。不过，同样，Gmail的示例在这里非常有指导意义。

我们已经发布了SQLite，使用SQLite实现Web数据库对我们来说肯定是阻力最小的途径。我们只是担心这对网络来说可能不是正确的事情。

当然，这就是Mozilla令人敬畏的原因。不管WebSQL有什么优势，你都不能说Mozilla在扼杀它的时候没有考虑到Web的最大利益。

Stachowiak的反驳有些软弱，他对O‘Callahan的大部分观点不以为然，但提出了Web SQL对开发人员更好的实用主义论据：

对于许多用例，具有大量高级概念(包括某种查询语言)的数据库层似乎更容易直接针对其进行编码。因此，应用程序员，特别是在额外抽象层特别昂贵的环境中。

[此外，]一些移动Web开发人员特别对SQL进行了现有的投资，作为一种模型似乎对它没有问题。抛弃他们将是一种耻辱，因为在许多方面，他们都是离线Web应用程序的先驱，而不是主流的专注于桌面的Web开发人员。

在我看来，SQL并不是适用于所有存储用例的最佳解决方案。但是，因此说它应该脱离Web平台(而不是仅仅通过其他工具来增强)似乎是一个相当激进的观点。这似乎不能满足其他用例的需要。

>；因此，指定>；SQL方言似乎没有实际好处。因此，在场的人表示，他们对>；指定SQLite v3为方言感到满意。

那到底是什么意思？它是SQLite的特定版本吗？几乎每个SQLite版本，甚至是点版本，都增加了功能。

SQLite几乎在每个版本中都捆绑了新特性、错误修复和性能改进，这使得在上构建一致的Web API变得特别困难。您是否已将SQLite导入冻结到特定版本？或者，您是否通过解析和验证查询来限制SQLite方言？或者，您是否允许在更新SQLite导入时定期更改方言？

我认为有一个共识，那就是指向一堆C代码不是为Web设定标准的好方法。这就是为什么我们编写规范，并且需要独立的实现，所以我们甚至不会意外地依赖于特定的C代码堆。这似乎与之背道而驰。

奥卡拉汉的另一大看点。我记得我编写了一个Cordova应用程序，实际上我必须从sqlite_master表中获取SQLite版本，以便确定支持FTS的哪些功能。不是很漂亮。(不过，公平地说，我们Web开发人员对这种黑客攻击并不陌生；找个时间看看jQuery源代码就知道了。)。

在这条线索中有一些来回的东西，查尔斯·麦凯西·内维尔(歌剧院的)跳进来调解了一下。他们讨论了性能，以及是否可以保证IndexedDB的大O性能。最终，尼昆吉·梅塔(Nikunj Mehta)拥有最后决定权：

WebSimpleDB将始终保持直接使用的易用性，即使它也将支持那些想要在顶层使用库的人。人们是否仍然喜欢使用库，将取决于他们的用例。具体的用例将有助于找到更客观的问题解决方案。

因此，这里我们到达了IndexedDB的一个主要卖点：它是低级的-比SQL低得多-所以它不是为开发人员直接使用而设计的。事实上，我倾向于认为IndexedDB是LevelDB(至少在Chrome上)之上的一个薄薄的事务层，它本身最好被描述为构建数据库的工具，而不是数据库本身。

此外，通过使用PouchDB(我们支持所有这三种Web SQL、IndexedDB和LevelDB)，我可以确认第一种是最容易使用的，而最后一种是最难使用的。IndexedDB绝对不同于原始的LevelDB，但是它无法接近Web SQL的各种工具包所提供的灵活性。(免责声明：其他作者可能不同意。)。

因此，让我们回到Mehta的原点：IndexedDB设计得足够低级，可以由JavaScript库来填补这一空白。同样，自从jQuery出现以来，没有人使用原生XMLHttpRequest或DOMAPI，假设库作者会填补IndexedDB笨重API的空缺。

虽然我认为自己是这群人中的一员(提示，提示：试试PouchDB)，但事后看来，我想评估一下这个计划实施得有多好

..