超越 HTML5：数据库 API 和 IndexedDB 之路

IndexedDB 是一种不断发展的 Web 标准，用于在浏览器中存储大量结构化数据，并使用索引对这些数据进行高性能搜索。Mozilla 针对该规范提交了大量技术反馈，我们计划在 Firefox 4 中实现它。我们与著名的 Web 开发者进行了交谈，讨论了如何为 Web 开发一个优雅的结构化存储 API。虽然 Safari、Chrome 和 Opera 的版本支持一种名为Web SQL 数据库的技术，它使用SQL 语句作为传递给 JavaScript API 的字符串参数，但我们认为开发者美学是一个重要的考虑因素，并且这是一个针对客户端 Web 应用程序特别不优雅的解决方案。我们把开发者反馈带给了IndexedDB 规范编辑，并且还与微软交谈，他们同意我们IndexedDB 是 Web 的一个不错的选择。随着 Chrome 团队正在进行的额外实现，我们认为解释我们的设计选择是值得的，以及为什么我们认为 IndexedDB 比 Web SQL 数据库更适合 Web。

Web 应用程序已经可以在 IE 8+、Safari 4+、Chrome 4+、Opera 10.5+ 和 Firefox 2+ 中利用localStorage 和 sessionStorage 来存储键值对，并使用简单的 JavaScript API。现在广泛实现的Web 存储标准（包含 localStorage 和 sessionStorage）对于存储少量数据很有用，但对于存储大量的结构化数据就不那么有用。虽然许多服务器端数据库使用SQL 来以编程方式存储结构化数据并有意义地查询它，但在客户端，在 JavaScript API 中使用 SQL 一直存在争议。

SQL？哪种 SQL？

许多 Web 开发者肯定熟悉SQL，因为许多开发者接触的服务器端代码（例如 PHP 和数据库操作）与客户端代码（例如 JavaScript、CSS 和标记）一样多。但是，尽管 SQL 享有普遍性，但没有一个规范性的 SQL 标准来定义该技术。特别是，SQLite 支持大部分SQL-92，有一些明显的遗漏，并且 WebDatabase API 是基于它的。但 SQLite 本身并不是规范——它是一种发布就绪的技术！而关于 SQLite 使用的 SQL 支持子集的最佳定义是SQLite 手册。为了真正理解 Web SQL 数据库，我们首先要开始为 Web 应用程序定义一个有意义的 SQL 子集。为什么要定义另一种语言，而 JavaScript 本身存在更优雅的解决方案呢？

SQLite 的优点和缺陷

我们认为 SQLite 对于应用程序来说是一项非常有用的技术，并且将其提供给Firefox 扩展和受信任的代码。我们认为它不是向通用 Web 内容公开的 API 的合适基础，原因至少是，没有一个可信的、广泛接受的标准可以以有用的方式对 SQL 进行子集划分。此外，我们不希望 SQLite 的更改将来影响 Web，也不认为利用主要浏览器版本（和 Web 标准）来使用 SQLite 是谨慎的做法。IndexedDB 没有这个问题；即使我们对 IndexedDB 的底层实现可能是基于 SQLite 的，但我们通过公开一个不基于 SQLite 支持语法的 API 来让开发者免受 SQLite 更改的影响。

美学和 Web 开发者

去年，我们在 Mozilla 校园举办了一次峰会，讨论 Web 上的存储。我们邀请 Web 开发者与我们讨论 Web 上理想的结构化存储 API。许多人确实表示接受基于 SQLite 的 API，因为他们已经尝试了某些浏览器中 Web SQL 数据库的版本，并声称流通中的东西比一组想法更好。然而，所有人都对更好的设计选择表示热情，以及更简单的模型如何让他们生活更轻松。我们看到开发者在白板上画了一个简单的BTree API，该 API 满足了他们的应用程序存储需求，这激励我们考虑其他选择。我们决心，使用表示 SQL 命令的字符串缺乏“Web 原生”JavaScript API 的优雅，并开始寻找替代方案。与微软一起，我们发送了关于 IndexedDB 提案的反馈，并积极参与了标准化工作。

在另一篇文章中，我们比较了 IndexedDB 和 Web SQL 数据库，并注意到前者在语法上比后者简单得多。IndexedDB 为第三方 JavaScript 库留出了空间，以使用 BTree API 来跨越底层原语，我们期待看到像BrowserCouch 这样的项目在 IndexedDB 之上构建。勇敢的 Web 开发者甚至可以在 IndexedDB 之上构建 SQL API。我们特别欢迎在 IndexedDB之上实现 Web SQL 数据库 API，因为我们认为这是技术上可行的。从基于 SQL 的 API 开始用于浏览器原语并不是正确的第一步，但对于基于 SQL 的 API 来说，在 IndexedDB之上肯定有空间。

我们希望继续与 Web 开发者就 Web 上的存储进行讨论，因为这有助于我们构建关于产品功能和未来 Web 标准的想法。我们期待看到下一代 Web 应用程序支持对索引数据的进行高性能搜索，并看到 Web 应用程序在“飞行模式”下更加健壮地工作。

链接

arunranga.com/blog

Arun Ranganathan 的更多文章…

117 条评论

[...] 较旧的文章 [...]

2010 年 6 月 1 日下午 11:44
匿名

FYI：您的链接https://hacks.mozilla.ac.cn/2010/05/comparing-indexeddb-and-webdatabase 应该是https://hacks.mozilla.ac.cn/2010/06/comparing-indexeddb-and-webdatabase/

2010 年 6 月 1 日下午 12:34
1. Shawn Wilsher
  
  谢谢，我已经修复了它。
  
  2010 年 6 月 1 日下午 1:25
马修

在http://news.ycombinator.com/item?id=1395818 上有一些有趣的评论

2010 年 6 月 1 日下午 3:25
史蒂夫·安塔尔

我似乎不明白为什么 Mozilla 一直在自毁前程。

一个封装了 SQL 的框架，抱歉，这太不令人印象深刻了。为什么不给我 SQL，让我自己编写框架呢？是我（作为 Web 开发者）太无能了吗？

SQLite 有文档，如果不够好，那就与微软、谷歌和 Opera 合作编写一个。有那么难吗？

有一个每个人都同意使用的实现优于编写另一个标准。

我真的讨厌组织总是认为自己比开发者更了解什么是最好的。讽刺地说，我认为如果你真的想要这样做，最好的办法是使用一个 JavaScript 包装器来包装这个 IndexedDB（你说写一个很容易），并且给我一些在任何地方都能正常工作的 SQL。

如果你真的认为你有一个更好的解决方案，就给我们吧，但请也给我们我们糟糕的解决方案，以防万一情况正好相反。让我们选择对我们最好的！

2010 年 6 月 1 日下午 4:05
1. Arun Ranganathan
  
  史蒂夫，
  
  感谢您的评论。现在，微软和 Mozilla 都不支持 Web SQL 数据库 API。为了真正给你 SQL，我们必须首先为 Web 标准化 SQL 的一个子集。仅仅说“做 SQLite 所做的事情”并不是一个好标准。此外，这使得所有现有的实现都绑定到 SQLite，而我们确实想要避免这种情况。所有现有的实现都使用 SQLite。我们不希望出现 SQLite 版本之间发布的变化导致不稳定性的情况；我们已经在我们的 mozStorage API 中向扩展公开这一点，我们不想将其暴露给 Web 内容。
  
  我们实际上确实与开发者讨论过这个问题。IndexedDB 允许各种可能的用例，但我完全同意，引入 btree 风格模型 *或甚至* SQL 模型的 JavaScript 库将很有用。事实上，我们预测，库将为结构化存储做与它们为 Web 的其他部分所做的一样——创建语法简化和更好的抽象。
  
  您目前是否在任何项目中使用 Web SQL 数据库，这可能是现在只有 Safari、Chrome 和 Opera 使用的。您是否认为代码无法移植到 IndexedDB？如果您能给我一些指针，我很乐意了解更多信息。
  
  再次感谢您的评论。
  
  — A*
  
  2010 年 6 月 1 日下午 5:44
  1. Marcelo Cantos
    
    我相信几乎任何 SQL 语法都可以移植到 IndexedDB，就像它也可以移植到 x86 汇编语言一样。但这并不是重点。比较页面中的最后一个例子完美地解释了为什么任何有常识的人都不会使用 IndexedDB。
    
    请告诉我，解决这个荒谬冗长且神秘的 API（我从未见过如此难以理解的循环结构）的方法，不仅仅是等待一个不是 SQLite 的 SQL 包装器。
    
    2010 年 8 月 30 日下午 4:46
  2. Fazal Majid
    
    我们不能记录和标准化 SQLite 的 SQL 方言的说法是荒谬的。所有现代操作系统都使用基于 BSD 4.2 的 TCP/IP 协议栈，并且不同版本之间存在细微的差异，例如 TCP SACK。我们应该放弃 TCP/IP 并使用 SNA，仅仅因为没有独立的协议栈实现吗？
    
    2010 年 9 月 1 日上午 10:47
史蒂夫·安塔尔

实际上，我曾经开发过一个应用程序来试用 Google Gears，它非常棒（能够编写这样的 Web 应用程序），只需很少的努力，我就可以创建离线数据并将其与 MySQL 数据库同步。简而言之：它有效，它让我觉得这个功能需要尽快出现在所有浏览器中。

另一方面，IndexedDB API 看起来很像我在服务器端所做的东西。是的，我实际上在 MySQL 上面用 PHP 实现了一个类似 IndexedDB 的 API，以下是一些问题

– 最终它没有比使用 SQL 带来任何真正优势
– 其他开发者不理解它，而且有些人不喜欢学习新东西
– 我最终编写了比使用 SQL 时更多代码
– 它使一些简单的操作变得困难，并且使复杂的操作几乎不可能

我编写的代码应该是可移植的，因为它没有使用复杂的层次结构。然而，问题在于，在服务器端我使用 SQL，而在客户端我将使用 IndexedDB……这使得生活比原本更困难。我知道服务器端和客户端数据库查询之间仍然会有一些差异，但它们几乎相同，这确实很有帮助。

我真的认为我们需要一个 SQLite 的最小子集，它应该始终有效，客户端数据库不应该拥有服务器端数据库的所有“酷”功能。

是的，我同意这一点，就像几乎所有其他事情一样：存储很糟糕，但一个基于 JS 的库将会出现并拯救世界。我已经看到 YUI Storage 的出现。

2010 年 6 月 1 日下午 11:12
Tim Lind

我期待着 IndexedDB，但看起来 IndexedDB API 引入了明显的灵活性不足，涉及将索引遍历绑定到行数据。

我很高兴索引由实现处理，因为这显然难以实现，但我一直想知道，为什么我们只暴露了完整的效果，当你已经将 BTree 本身放入浏览器时，为什么不直接向我们暴露 BTree，这样我们就可以将其用于可能不需要整行数据和多个索引的其他用途？

这与 localStorage API 相同。我们只获得一个存储容器，带有计数和迭代，当你已经完成所有工作时，让我们创建一个新容器将是微不足道的，而且实际上非常重要。这不是我们可以通过 API 实现的东西。因此，你已经完成了工作，但你仍然没有为我们提供基本构建块，这些构建块可以让我们拥有更大的灵活性。这似乎很奇怪。

2010 年 6 月 2 日上午 0:45
Tim Lind

实际上，并没有真正的不灵活，也许是我看过的一个过时的草案，你目前的实现看起来很好，并且应该可以作为很好的构建块。

但我仍然认为，一般来说，需要更多关注提供构建块，而不仅仅是最终产品，特别是 localStorage API 如何未能做到这一点。

感谢你在这个规范上所做的出色工作。

2010 年 6 月 2 日上午 1:37
fpiat

为什么简单的事情非要复杂化。
在 15 年的 Web 开发后，我真的很厌倦所有这些新事物。我们必须了解 HTML、CSS、JavaScript、PHP、SQL，现在我们又有了另一个……用于管理数据的。当我看到这个规范时，我无法想象为什么人们会浪费时间去创造如此……微不足道的东西。
每个 Web 开发人员都了解 SQL。为什么还需要另一个 API？
为什么不面对像安全这样的真正问题呢？

2010 年 6 月 2 日下午 4:01
Mark Davies

我必须同意这里其他一些人的观点。我开发了一个使用 Web SQL 的 Web 应用程序，适用于 Safari 和 Chrome 浏览器。我通过谷歌搜索找到了这个页面，想知道你是否会以及何时实施 Web SQL。Web SQL 运行良好，易于使用。有一些很好的包装库可用。我们不能简单地标准化并让开发者开心吗？我毫不怀疑我能够*移植*我的代码。但我更希望有一套代码可以在任何地方都能正常运行。

2010 年 6 月 4 日下午 2:17
Brona

我忍不住，但我发现所有这些推理都是自私的
1/ SQL？哪个 SQL？
是的，SQLite 不支持完整的 SQL92，但哪个数据库支持呢？而且看起来所有编写服务器端代码的 Web 开发人员似乎都对此很满意，并没有遇到什么问题……而且抱歉，创建一个新的 API 并记录它，这个 API 对开发人员来说鲜为人知，而不是重写现有的 SQLite 文档以使其更适合，这似乎对任何人都没有好处。
2/ SQLite 的益处和弊端
同样，开发者（不仅仅是 Web 开发人员）每天都面临着同样的问题：新版本与旧版本不兼容。SQLite 已经相当快且功能强大。如果新版本不兼容，则无需升级。
3/ 美学和 Web 开发人员
在我看来，Mozilla 中没有开发者会在服务器端编写带有数据库访问的网页……我们每天都在混合使用各种技术……HTML、CSS、ECMAS、PHP、SQL……日常工作……
SQL 的优点在于它非常强大、非常容易学习，而且可以调整（可以玩弄查询）。
你不应该创建一些面向对象的接口，因为这是库和程序员的工作。这样，解决方案就可以满足个人的需求……而你的解决方案呢？据我所知，不支持多个键，对三个结构进行复合连接（在 SQL 中使用简单的联接很容易做到）意味着要花一整天时间使用数十行代码，这些代码充满了回调，使用游标进行遍历，进行疯狂的比较，实际上是重新发明 SQL

但这是你的选择，Chrome、Safari 和 Opera 已经有了自己的……Web 开发人员将做出选择，这不会帮助你……

2010 年 6 月 7 日下午 4:52
Brona

我的意思是，不要重新发明轮子，我们已经有一个了……
我想知道如果 WedDatabse 成为标准会发生什么……你会忽略它吗，因为你自认为更了解？

2010 年 6 月 7 日下午 4:56
1. Shawn Wilsher
  
  它很可能不会成为标准，因为规范的编辑草案目前是如此规定，因此这里没有太多讨论的必要。
  
  2010 年 6 月 7 日上午 10:34
  1. Sam Orchard
    
    这不是这些评论的意义吗？:P
    
    2011 年 4 月 29 日下午 2:08
Fazal Majid

用一个半成品的层次模型取代像 SQL 这样的将逻辑数据模型和物理数据模型分开的表达式语法，应用程序必须自己处理所有事情，这不仅仅是一步倒退，而是十步倒退。

2010 年 6 月 7 日下午 10:46
Tim Lind

我认为大多数评论者都误解了 IndexedDB 规范的关键方面，所以让我们澄清一些事情

– 所有 SQL 数据库都是构建在类似 IndexedDB 的 API 之上的，它模仿了旧的 ISAM API（长期存在于许多你使用的流行数据库之下）。

– IndexedDB 规范现在正在将该*底层* API 带入浏览器，从而提供*更多*选项，而不是更少。

– 浏览器上的 SQL *将会*可用，它将由用户加载的框架库创建，这样你就可以选择你的 SQL 方言和 SQL 库的函数 API。

– 替代的数据存储系统，这些系统更容易使用且更高效，也可以在 IndexedDB API 之上提供，因此我们不仅限于 SQL，这是该规范的意义所在。你仍然将拥有 SQL 功能。

2010 年 6 月 8 日上午 2:13
1. 史蒂夫·安塔尔
  
  为什么要实现一个已死的 API？
  为什么要做一个低级 API？
  在这种情况下，为什么不直接提供 fread() 和 fwrite()，让开发人员用 JavaScript 编写整个数据库引擎呢？我知道这没有意义，但这与 IndexedDB 基本相同，它太低级了！
  
  这件事让我想起了 innerHTML，它不在标准中，标准组显然认为你应该用 JavaScript 编写一个 HTML 解析器，并使用 DOM 方法，这些方法很糟糕。
  为什么不能使用浏览器的 HTML 解析器？它比你用 JavaScript 编写的任何东西都快得多！
  
  在这种情况下也是如此，SQLite 是一个快速的 C 引擎，它有一个 SQL 解析器，速度非常快，那么为什么我们要在 JavaScript 中复制它？为什么我们要在浏览器中拥有 2 个 SQL 解析器（1 个在 SQLite 中，1 个在 JavaScript 中）？
  
  我可以用很少的代码在 SQL 之上编写一个 IndexedDB API，那么为什么要削弱 SQLite 呢？
  
  给我看看用户加载的框架！我不想等它出现，我现在就想用它！
  
  对不起各位，但我真的觉得这是一次巨大的倒退。
  
  2010 年 6 月 9 日上午 3:35
2. ged
  
  我完全同意 TIM。
  
  1. SQL 广为人知，但它最初是索引器之上的语法。
  因此，在 html5 的核心位置拥有一个索引器要好得多，这样就可以在上面实现更多 SQL 和 NoSQL 实现的组合。
  
  2. 我觉得很多开发人员都偏向于 SQL，因为它对他们来说很熟悉。我同意它很简单。但你都错过了重点。
  你在服务器上使用的 SQL 不会与你在客户端上使用的相同！！！
  能够在服务器和客户端上使用相同的数据存储 API 很好。每个人都会同意这一点，当然。
  因此，这允许所有开发人员访问 DRY 的能力，这可以应用于他们的架构堆栈。
  DRY = 不要重复自己。
  
  使用 Index DB，将会有与 MS SQL、Oracle SQL 等等效的包装器。你将获得 DRY。
  
  结论。
  html5 数据存储 API 和引擎的低级性和可包装性非常重要。
  Jquery、Dojp 和其他包装器已经成为 Web 开发的救星，因为它们弥合了不同浏览器版本之间的差距。
  IndexDB 之上的 SQL 包装器将做同样的事情。
  
  不将这种灵活性融入像 Web 这样重要的东西，就是架构上的自杀……
  Mozilla 正在试图避免来自 W3C 的当前 SQL API 中的 HACK。
  
  2010 年 10 月 21 日下午 12:28
  1. blago
    
    最后，我明白了。Oracle、SUN、Microsoft、MySQL、Sybase、SQLite 等公司在他们可以使用 jQuery 插件来写一些牛逼的东西的情况下，为什么要用 C/C++/汇编语言写那么多东西呢？
    
    这很有道理：据我所知，一个 SQL 引擎有一个查询解析器和几个 for 循环。我们可以在 50 行 JS 代码中实现所有这些功能。即使是 10000 行代码，谁还会关心下载时间呢？
    
    此外，我最近在某处看到，Nitro 在最坏情况下比 C++ 快两倍。每层解释的性能损失是 90 年代的产物。而且，数据访问并不像我们想的那样频繁。
    
    我对所有浏览器厂商有一个特殊的要求。为了遵循 DRY 原则（这意味着不要重复自己），我们可以提供行文件访问，这样我们就可以灵活地编写更高效的自定义索引。仔细想想，IndexDB 可以基于文件实现（我认为）。
    
    结论：去上个计算机科学课吧。
    
    2010 年 10 月 22 日下午 5:18
Brona

Tim: 在 SQL 之上编写面向对象的接口比在对象/回调导向的 API 之上编写 SQL 容易得多。其次，数据库已经针对速度和性能进行了优化，这是在创建管理大量相关数据的工具时最困难的任务之一。在处理关系方面，SQL 比这种乱七八糟的东西要容易得多，在 IndexedDB 上构建真正快速的 SQL 接口就是在重新发明轮子（所以选择是重新发明轮子，或者学习一些似乎效率较低且没有明显好处的东西）。最后一段就像一个笑话：可以在 SQL 引擎之上提供一种更容易使用且更高效的替代数据存储方式，所以我们不只是受限于 IndexDB API。这是当前 WebDatabase 规范的目的。你仍然可以拥有 IndexedDB 的功能……在我看来，这更连贯。每个程序员都在 SQL 之上编写了对象层，并享受了简单但强大的查询语言带来的好处。我想知道有多少程序员能够在 IndexedDB 上创建包含相关对象的数据库，并且效率类似。
但再次强调，假设 WebKit 和 Presto 支持 WebDatabase，最终选择权将掌握在 Web 开发人员手中。

2010 年 6 月 8 日上午 4:00
jonathan chetwynd

这篇文章没有提到 XML，尤其是原生 XML 数据库。

你能否评论一下这些提议中如何整合 XML 数据？

2010 年 6 月 9 日上午 3:46
InfiniteRand

住在玻璃屋里的人不应该扔石头。有多少浏览器实现了完整的 DOM API？如果一个浏览器厂商认为其开发人员专注于与桌面环境集成的应用程序需要一个完全不同的 DOM，那么 Web 开发人员也许可以重新在这些东西之上实现当前的 DOM API。

2010 年 6 月 10 日下午 6:00
Greg Quinn

我必须同意 Steve Antal 的观点，Mozilla 一直在自断后路。我目前正在编写网站应用程序，需要能够在客户端高效地存储兆字节的数据，Mozilla、Chome 和 Safari 都表现出色。SQLite 非常有效。就这么简单；提出关于他们是否会在未来改变 API 的假命题——那又怎样？使用微软对 IndexDB 规范的接受是（用奥斯卡·王尔德的话说），坦率地说，是无赖的最后堡垒。老实说，现在我的印象是，你们住在一个象牙塔里。首先是 Shaver 关于 H264 的言论，现在又是 SQLite，Firefox 一年前就应该实现它。我真的不喜欢这种客户端 API 的碎片化。如果继续这样下去，你们会把自己逼到绝路的。

2010 年 6 月 13 日下午 10:17
Brett Zamir

根据 jonathan chetwynd 的提示，我在 https://hacks.mozilla.ac.cn/2010/06/comparing-indexeddb-and-webdatabase/comment-page-1/#comment-95595 上发表了一条评论，支持 XML 数据库。

2010 年 6 月 17 日下午 8:10
1. jonathan chetwynd
  
  还没有机会尝试浏览器中的 XQuery 支持，
  
  但 XSLT 支持非常出色。
  http://www.peepo.com/games/Shusai-GoSeigen-19340119.xml
  从笔记本电脑运行，所以……
  
  一个简单的游戏玩家。
  
  2010 年 6 月 23 日上午 1:32
Federico

如果你不提供 Web SQL 存储，你会造成两大损失。

第一，

Firefox 将会失去一大批用户：我们正在开发一个使用 Web SQL 存储的 Web 应用程序（它真的很棒），我们很快就会向所有用户推荐 Chrome。我相信我们不是唯一一家在开发这个真正优秀标准的企业/开发者：其他企业/开发者也在做同样的事情。

Web SQL 存储很好地解决了复杂应用程序离线使用的问题。你们有更好的标准吗？好吧，你们也可以开发它。*太*了。W3C 关于 Web SQL 存储的规范已经定义得很清楚：同时，开发它们也不应该是个坏主意。

第二，你们让开发者们的生活更加艰难。Firefox 中缺少此功能真的很令人沮丧：我们不得不强迫用户使用其他浏览器，这会让我们的应用程序更难分发和使用。

我不喜欢 Google。请继续让我们有机会再次依赖 Mozilla 基金会。

2010 年 6 月 20 日下午 5:25
Rastaman

我同意之前的开发者的观点，强迫我们使用新技术而 SQL 已经能够完美完成工作，这真的不好。用面向对象的方式执行复杂的查询（比如计算账单、税款等）会很痛苦，而我们可以在一行 SQL 代码中完成这些操作。因此，在这方面，你们失去了我作为开发者的支持，而且你们显然没有听取所有批评这一决定的开发者的意见。如果在 IndexDB 上很容易实现一个原生 SQL 解释器（它的速度与 Webkit 中的 Web SQL 一样快），就去做吧，用您自己基于索引数据库的实现来支持 Web SQL 规范，并满足我们的需求：你们曾经得到过社区的支持，对吗？或者，是你们的赞助商（Oracle 等）不想让 SQL（没有由他们发布）出现在客户端？

2010 年 6 月 26 日上午 2:59
Nevio

我也要说明几件事。

正如我在之前的帖子中看到的，我理解你们都希望在实现之前有一个好的、标准化的功能，但不幸的是，例如，

我正在开发一个充满了 HTML5（WebSockets、WebSql、localStorage 等）的社交媒体服务。我根本无法也不想编写一堆服务器端或 Java 代码来获得某种可扩展性。等等……服务器端和可扩展性 + 实时平台 == 糟糕！（抱歉用了粗话）所以你明白我的意思了吧……

令人沮丧的是，现在我需要强迫 Firefox 用户安装 Google Gears，这将是一个糟糕的解决方案，因为我已经禁止所有 Internet Explorer 用户访问我的平台。（也许以后会支持 IE9）。

正如 Federico 所说，我再说一遍。有时候，做个追随者比做正确的事情更好。使用 Web SQL 数据库的开发人员完全意识到它可能会给项目带来的损害，但你知道吗……

去夏威夷，在高级餐厅吃饭等等……万事达卡可以买！
Web SQL 数据库不行！它是无价的！哈哈！

2010 年 6 月 28 日下午 4:33
Blago

“为什么定义一门全新的语言，当 JavaScript 本身已经存在更优雅的解决方案”？

这句话没有意义。JavaScript 没有现有的解决方案来查询结构化数据。实际上，我们将不得不学习一种全新的方法来设计架构并查询数据。现有的解决方案叫做“SQL”，如果我们能够在客户端和服务器之间共享一些代码/架构，那将是一件非常令人欣慰的事情。我不害怕更改一两个关键字。

如果你一定要发明一些新东西，那就让 John Resig 设计一个类似 jQuery 的选择器/过滤器 API——这样很优雅，而且我们也熟悉它。

速度是另一个重大问题。我绝不会自愿为数据库中的每一行运行一个 JS 回调，只是为了过滤掉除了我需要的几个对象之外的所有对象。这简直是疯了。我们正处于移动设备的时代。任何理智的人都应该让 C 代码（借助索引）来处理这些事情。

至于代码的优雅程度……看看这里最后的 SELECT 示例：https://hacks.mozilla.ac.cn/2010/06/comparing-indexeddb-and-webdatabase/ 。

2010 年 6 月 29 日上午 11:14
Guido Tapia

有人知道是否有任何抽象的 JS 库可以实现 indexdb/websql 透明性？也许甚至可以为 IE 提供 localStorage 作为后备？

2010 年 7 月 10 日下午 10:12
1. Sam Dutton
  
  问得好。你找到什么了吗？
  
  persistence.js 做了一些类似但不同的事情。
  
  2011 年 3 月 26 日上午 4:30
  1. JJ
    
    有一个名为 lawnchair 的 Javascript 库——http://westcoastlogic.com/lawnchair/——它似乎是数据请求和数据之间的抽象层。它声称支持 WebSQL 和 IndexedDB。
    
    2011 年 8 月 12 日下午 9:02
Komrade Killjoy

用户存储已经过时了。

把所有东西都存放在由一个巨型数据挖掘实体拥有的“免费”云中。

借助方便的美国联邦数据存储法，他们“可以”比以往更长时间地存储有关主题——错误，我指的是公民的信息。

双赢。

2010 年 7 月 28 日上午 6:24
pkario

真的，没有一个关于不实现 Web SQL 数据库的论据是合理的。
* SQLLite 已经存在，
* 大多数开发者不想回到 dbase III+（即使像我这样的老程序员也不想），
* 当然，你们比我们更了解什么是好的，但是……

如果你们需要我们求求你们，
求求你们……
实现 Web SQL 数据库……

2010 年 7 月 31 日上午 4:02
1. Greg Quinn
  
  Mozilla 似乎有意成为多余的；在使用 SQLite 完成一个客户端持久化项目后，它感觉就像一个改变游戏规则的人，它在行动中闪电般快速，易于实现，而且调试速度很快。幸运的是，还有其他支持 SQLite 的跨平台浏览器，Mozilla 不再是唯一一个作为多平台浏览器选择的竞争者。“SQL？哪个 SQL？”这个标题仍然让我又生气又难过。
  
  2010 年 7 月 31 日下午 1:56
sri

您可以在 http://tinyurl.com/ff-idxdb 上找到一个索引数据库游乐场。它包含 API 的示例。我写了它，因为我找不到其他地方的文档。希望对您有帮助。

2010 年 8 月 4 日上午 0:57
meh

这个切换能解决拥有非常非常大量的书签收藏带来的巨大延迟和内存占用问题吗？

这些会使向嵌套标签过渡变得更容易吗？

2010 年 8 月 5 日下午 3:41
Marcelo Cantos

我刚刚点击了 Chrome 团队提供的页面链接。我最喜欢的一段是这个

问：为什么是它而不是 WebSQLDatabase？
答：微软和 Mozilla 已经明确表示他们不会在浏览器中实现 SQL。如果你认为这是愚蠢的，请找他们理论，别找我。

这段话很好地概括了我到处看到的氛围。除了 Firefox 和微软之外，似乎没有人同意这种方向。我怀疑微软只是想将网络绑定到 T-SQL，而 IndexedDB 甚至缺乏查询语言的基本要素，将为他们提供完美的借口。

相关地，我认为在没有表明他们的立场截然不同的情况下，将微软和 Chromium 团队一个接一个地提及，有点不诚实。这会让人以为 Chromium 团队和微软一样乐于接受这种方案，而事实显然并非如此。

2010 年 8 月 31 日上午 6:09
Jason

把我加到失望的名单里。我感谢 Mozilla 的人们为除了（稀缺的）赞誉之外几乎没有得到任何东西而付出的所有努力。话虽如此，我认为他们做出了错误的选择。其他浏览器为我们提供柠檬水，而 Mozilla 给我们柠檬、水和甘蔗，并告诉我们能够精确地制作我们想要的柠檬味饮料是多么美妙。我预见到，最终，有人会将 JavaScript 库拼凑起来，从 Indexed DB 中获得一个 SQL 的兼容性层，用于 Mozilla 和 IE。它将比 Safari、Chrome 和 Opera 的原生实现更慢。最终，速度差距会变得足够尴尬，以至于 Mozilla 会追赶并最终实现 Web SQL。IE 可能永远不会实现，因为他们有病态的需要变得毫无用处。

正如其他发帖人已经提到的那样，反对 Web SQL 的理由相当薄弱，而且很容易反驳。它带有对已经做出的决定的逆向辩解的味道。作为一个从第一天起就一直将 Firefox 作为其主要浏览器的用户，这让我感到难过。

2010 年 9 月 1 日下午 6:30
1. greg
  
  为了公平起见，关于微软不愿意实现 SQLite 持久层，我认为他们不太可能支持分发他们自己的 SQL 引擎以外的任何 SQL 引擎，并且我相信他们有有效的商业理由在内部使用它来证明这一点。我希望他们能将 SQL Server Express 作为 MSIE 的一部分实现，作为一种替代方案，但我假设他们认为这在实现方面工作量太大，或者它与其他产品路径竞争。作为一家公司，他们有权为公司利益做出他们认为最好的选择。因此，利用微软作为 Mozilla 不实现 SQLite 持久层的荒谬决定的某种拐杖，简直是荒谬可笑。我真的希望你们能做得更好。
  
  2010 年 9 月 2 日上午 10:29
  1. Christopher Blizzard
    
    Greg，我已经在另一篇文章中回复过你，你在那篇文章中用相同的语气说了几乎相同的话。很抱歉你不同意我们在这方面的决定。
    
    2010 年 9 月 9 日上午 10:11
Blago

Greg，对于你做出的决定我感到抱歉，因为这条帖子中的几乎每个人都不同意你。

2010 年 9 月 9 日上午 10:39
1. 史蒂夫·安塔尔
  
  Blago，实际上包括我在内的大多数人，都同意他的观点。我对 Mozilla 非常失望，因为它似乎 Firefox 开始成为新的 IE6。
  
  2010 年 9 月 9 日上午 10:42
  1. Christopher Blizzard
    
    确实如此！
    
    2010 年 9 月 9 日下午 2:25
    1. Brett Zamir
      
      当然，Mozilla 团队正在努力添加音频和视频等有用技术，并在多个方面进行创新，而就开发者便利性（E4X、固定的对象迭代顺序等）而言，主要还是其他浏览器需要赶上来，尽管像我长期以来的抱怨一样，没有外部 DTD 支持或撤回 enablePrivilege 支持。我认为那些支持 SQLite 的人也可以稍微冷静一下，认识到毫无疑问，一些 SQLite 层最终会到来，即使这需要在每次我们想要使用它时添加一个脚本标签。
      
      但我同意以任何代价追求速度的观点（并且我要补充一点，“以任何代价简化界面”）。这不仅仅是关于用技术可以做什么（尤其是对于 Google 和 Apple 等人主导 HTML 方向，以及他们拥有更多资源来利用这些技术的感觉），而是对于普通开发者来说，这样做有多么容易和健壮，以及如何在不久的将来做到这一点。
      
      也许 Mozilla 中推动这一想法的人可以实际实现至少一些 SQL 层的概念证明（SQLReallyLite），如果它可以为习惯于这种模型的数据中心人群完成，或者至少创建一个可以处理数据连接等的语法。
      
      在心理学中，他们说对于你想要消除的任何行为，你需要提供一个替代方案，否则就会出现真空。Mozilla 应该预期在删除或甚至计划删除功能时遇到一些阻力，尤其是如果它没有提供更好的替代方案（不仅仅是在某些方面更好），尽管我们应该认识到时间并不总是受你控制。
      
      就我个人而言，我已经开始在 http://code.google.com/p/jsxqueryparser/ 上工作，试图最终将 XQuery 支持引入 JavaScript（尽管一个 jQuery 插件，它允许查询多个文档，在使用 IndexedDB 时会非常容易实现（尽管不安全地完全暴露给用户）；我只是喜欢 XQuery 的语法及其缺乏对 JavaScript 的完全暴露，而一个 jQuery 插件需要允许这样做，除非它使用 JS 解析器来对允许的语法进行子集划分）。
      
      此外，XQuery（一个规范，由创建 SQL 的人共同编辑），除了允许关系式连接（参见 https://wikibooks.cn/wiki/XQuery/XQuery_from_SQL#Table_Joins ），它还具有比 SQL 更容易理解（更强大）的语法，并且适用于分层（文档中心数据）和关系数据（并且可以直接在像 XHTML 表格一样熟悉和透明的东西上工作）。
      
      我个人认为 XQuery 或修改后的 jQuery 将是替换 SQL 并让网络重新开始（从我的感觉来看，而不是 map-reduce）的绝佳候选者。因此，如果浏览器不支持 XQuery，那么我希望我们能够将 XQuery 引入浏览器。欢迎志愿者（brettz9 – yahoo）。
      
      我们确实感谢你在 Mozilla 的所有努力和创新工作！这就是我们对它充满热情的理由……
      
      2010 年 9 月 9 日下午 7:58
      1. Marcelo Cantos
        
        SQLite 层？？SQLite 既不是 API，也不是语言，也不是标准；它是坚如磐石、经实践检验、高性能、600:1 测试代码与生产代码的数据库引擎，它作为一个 .h 文件和一个 .c 文件提供（忽略辅助文件：shell.c、sqlite3.def 和 sqlite3ext.h）。它是一件纯粹的杰作，你不可能希望用几周（或者坦率地说，几个月）的努力在一个小项目中匹配它。事实上，我怀疑通过 IndexedDB 之上的层来匹配 SQLite 的强大功能甚至是不可能的。
        
        人们真正困扰的不是你将无法使用 SQL，而是真正出色的软件，它迄今为止已经取得了惊人的成果，却被无情地抛弃，取而代之的是一种重写世界的策略，这种策略在至少几年内无法在可靠性、性能和整体成熟度方面与它相提并论。坦率地说，两年时间过于乐观，因为 IndexedDB 不会让微软或 Oracle 放弃他们自己的“轻量级”引擎。每个人都必须回到起点，从头开始构建自己的基于 IndexedDB 的 SQL 引擎。而现有的引擎最值得称道的部分（稳定性和数十年的优化）将无法迁移到这些新的实现中。
        
        2010 年 9 月 12 日上午 3:20
      2. Brett Zamir
        
        我理解对实现可能性和选择的担忧，我不会就这个问题发表立场；我的观点仅仅是，这里许多抱怨是关于 API 的，而没有为此做好准备，我认为这是让开发者感到沮丧的主要原因，他们至少希望有一些熟悉（或至少相似）的方法来继续他们获取数据的旧方法。
        
        作为 XML 数据库的爱好者，我也对实现能力感到担忧，因为我想知道 IndexedDB 是否原则上可以支持性能同样高的数据库。
        
        2010 年 9 月 12 日上午 4:48
  2. Blago
    
    这是一个笔误。我的评论是针对 Chris 的。很明显，这条帖子中很少有人（如果有的话）支持 IndexedDB。
    
    2010 年 9 月 9 日下午 6:09
Blago

我也认为 Mozilla 的人脱离了实际，并且处于否认状态。顺便说一句，五年前我为《纽约时报》的广告捐款，所以当我这么说的时候，我感到非常痛苦。

今天看来 Mozilla 并不关心开发者。想想看。FireBug 在 Joe Hewitt 负责时非常棒，但自从他离开后就变成了一个巨大的 BUG。与此同时，Webkit 创建了 WebInspector，它是浏览器的一部分，并且与浏览器一起维护，并且在使用一段时间后，它就像一个冠军一样运作。

2010 年 9 月 9 日下午 6:24
Meni

我刚读了这篇文章，还没看评论，所以请原谅我匆忙评论，如果我让自己出丑，那只是因为我对此事感到强烈。这难道不是 SVG vs VML 的翻版吗？据我所知，当时是自我和骄傲，而我们都因为这样而输了。如果我们当时达成一个矢量标准，那么今天网络将会更好。

我所主张的是，让来自 Google、Apple、MSFT、Mozilla 和 Opera 的人聚在一个房间里，谁也不许离开，直到出现白烟为止。让网络快速向前发展。在他们被锁在那里的时候，请分配披萨 :-)

天哪，如果 JavaScript 是由你们这些家伙创建的，我们今天可能还在等它 ;-) 如果有什么教训需要吸取，我认为就是：选择一些已经存在的东西，谁在乎它是否完美，没有人会因为这个把你送进监狱。

祝好（顺便说一句，感谢 FF，我离不开它）

2010 年 9 月 19 日上午 1:13
Jaka Jancar

我喜欢你如何将此说成是一件坏事

“但 SQLite 本身不是规范——它是一个可发布的技术！”

2010 年 9 月 27 日下午 1:56
Terry

强烈支持 Web SQL 数据库。

Terry

2010 年 10 月 12 日上午 7:50
Martijn Otto

我认为所有的事情之前都说过，所以我不会在这里发表长篇大论。我只想让大家知道，Firefox 中缺少 SQL 确实是一个非常、非常大的失望。

2010 年 11 月 5 日下午 3:01
dennis

荒谬。这又给了我一个抛弃 Firefox 的理由。

2010 年 11 月 22 日上午 11:15
axmcomp

正如大多数发帖人已经说过的，这种理由仅仅是对出于纯粹政治原因做出的糟糕决定的事后合理化。

事实仍然是开发者想要的是一个 SQL 接口，而不是一个糟糕的 btree 接口。我不想为了完成工作而重新发明 SQL。

话虽如此，根据我的经验，这主要影响移动开发者，因为我们正在开发复杂的基于 JavaScript 的 Web 应用程序。由于大多数浏览器都是基于 WebKit 的，因此它们将继续使用 WebSQL，所以这个决定虽然让人有些担心，但不会在中期产生任何影响（假设他们可能需要 5 年的时间才能达成协议并实施）。

我认为这将是另一个 Mozilla 等最终会夹着尾巴认输，实施其他所有人都在使用的方案的案例，因为否则 Firefox 将变得比现在更不受欢迎。

当你冷静地看待这两种技术时，你会发现其中一种比另一种领先了上万英里。

2010 年 12 月 12 日下午 6:02
Ramin

我是一名 Web 开发人员，想用 HTML/CSS/Javascript 和 SQL 来编写智能手机应用程序。
我已经有一些 PHP 服务器脚本，它们使用 SQL 并与我的客户端 HTML/Javascript（Ajax）进行通信。现在我想编写脱机应用程序，这些应用程序使用本地数据库而不是始终联系 Web 服务器。
有了 WebSQL，将我的在线应用程序移植到脱机应用程序非常简单。

Indexed DB 可能很好，但我需要更改代码中的很多内容。
Mozilla 不能同时提供 WebSQL 和 IndexedDB，让开发者自己选择吗？

2010 年 12 月 23 日上午 7:37
Li Zhou

我无法使用 Firefox 4 beta 8 打开 IndexedDB 数据库。
var request = window.moz_indexedDB(“candy”, “candy store”);

2010 年 12 月 28 日上午 9:46
Juan Antonio

很简单。没有 WebSQL，就没有 Firefox。

2011 年 1 月 10 日上午 0:36
vicm

IndexedDB 只是 Mozilla 的产品。开发者不必太担心它：没有所有主要浏览器的支持，我就不会使用它。就这么简单！
通常是 IE 会耍这种花招。现在，Mozilla 也想加入进来。

如果你认为 IndexedDB 是个好主意，那就实施它，同时实施 WebSQL。如果开发者喜欢 IndexedDB，所有浏览器迟早都会实施它。

2011 年 2 月 8 日下午 5:46
wHiTeHaT

很搞笑，我居然看到了这个讨论，因为在这种情况中我还是个新手。
但让我告诉你吧。
你可以想说什么就说什么，IndexedDB 和 SQL(ite) 将成为普通网站的标准。当然，这取决于浏览器。
对于使用支持 SQL 的浏览器的用户来说，肯定会出现麻烦。
在 Microsoft/Mozilla 浏览器上运行的用户可以从两者中获益。
这是一场市场战略，而且非常聪明。
让别人为你做这件事，而不是自己做所有事情。
浏览器和操作系统的战争即将结束。
最终目标是最终用户，一切取决于硬件。
如果每个浏览器都配备一个 CPU，那不是很棒吗？ ;)
那么，最后谁决定你运行什么软件呢？
硬件供应商。
他们让你以为自己买到了最好的东西。
哈哈，看到这个讨论真有趣，谁来洗碗呢？

2011 年 2 月 12 日下午 5:25
Remy97

我同意使用 NoSQL 方法。对于许多解决方案来说，关系模型过于复杂。我同意数据以 JSON 的形式进行结构化，但只需使用索引功能进行优化。我也喜欢 MapReduce 和未来扩展的理念。

2011 年 2 月 17 日上午 10:17
1. Marcelo Cantos
  
  如果你认为 SQL 过于复杂，那么你显然还没有看到 https://hacks.mozilla.ac.cn/2010/06/comparing-indexeddb-and-webdatabase/ 上的比较代码示例。
  
  2011 年 2 月 17 日下午 8:34
Sam Danielson

Sqlite 的类型系统与 JavaScript 完美匹配，例如 1 == ‘1’。事实上，它有一个类型亲和系统，速度很快，而且是为独立目的而开发的，这真是太棒了。即使 IndexDB 超越了所有预期，失去一部分 sqlite 仍然是一种损失。这是一个很棒的软件。如果必须包含 IndexDB，为什么不能同时拥有两者？拥抱、扩展……

2011 年 3 月 4 日下午 1:26
1. Sam Danielson
  
  没关系。sqlite 中的 1 ‘1’。令人惊讶的是，一个旧的假设可以持续多久而没有得到验证。
  
  2011 年 3 月 14 日下午 4:23
Kevin Layman

~~侮辱性评论已删除~~

2011 年 3 月 21 日上午 10:10
1. Paul Rouget
  
  侮辱别人对这里没有帮助。我会删除你发布的其他评论。你可能比 Mozilla + Microsoft + Google 聪明得多，但这不意味着你可以侮辱别人。
  
  2011 年 3 月 22 日上午 7:15
  1. Marcelo Cantos
    
    我重新阅读了我删除的帖子的副本。它们确实是强有力地表达了观点，但也从几个方面切中要害。当然，“白痴”和“笨蛋”之类的词最好不要说，但是，考虑到（在我看来）这个糟糕的决定，我理解凯文的情绪激动。而且，根据上面的评论内容，很明显他不是唯一持有这种观点的人；从头到尾，他的帖子都让我觉得，“没错，我也是这么想的！”因此，这些帖子对这场辩论做出了重要的贡献。
    
    除非帖子本质上具有攻击性（即，威胁性、下流等），否则没有理由删除它。你可以批评他语气不当，然后就此打住。如果你认为他的论点是错误的或没有根据的，那么适当的回应应该是反驳。
    
    删除凯文的帖子在我看来无异于通过审查来围堵。单方面否决他以后的帖子是一种耻辱。
    
    向社区表明你确实想听取我们的意见。恢复凯文最初的帖子。
    
    2011 年 3 月 22 日下午 2:48
Marcos Lima

我知道我的评论来得太晚了，但我对 IndexedDB 的担忧很感兴趣……

我只想将数据加载到本地客户端存储中，比如 JSON 数组、结构化对象、任何数据的简单数组，最后像 SQL 一样查询（使用简单的关系），比如面向对象的数据库。此外，将所有数据再次检索为对象会很不错……

我想你正在让这个 IndexedDB 变得过于复杂，因为你的目标是实现最前沿的技术……

尽可能简单吧！=)

谢谢，

Marcos Lima
系统分析师/Web 开发人员
巴西

2011 年 3 月 24 日上午 9:51
Marcos Lima

我想替换查询数据的策略方法，或者自己设置索引属性，以及创建内存视图，我认为这很有用，创建对存储修改的处理程序，比如按钮实际执行的事件。

2011 年 3 月 24 日上午 10:00
MarkIt

再说一次，HTML5 标准不是标准。蛋糕是假的。
对于每一个新功能，我们都要等到 jquery 出现一个东西抽象所有与浏览器的交互，从而消除浏览器开发人员认为他们自己的解决方案可以获得的任何优势。
在这一点上，我只希望 Adobe 将他们的标准 sqlite 包含在 flash 插件中……哦，等等，苹果那档子事。

2011 年 3 月 26 日上午 8:09
John Z

凯文·莱曼的评论切中要害。删除你认为有攻击性的部分，并回应他的技术观点。

审查很糟糕！

2011 年 3 月 28 日下午 4:38
Lucas

由于我不想重复其他人在这场讨论中已经说过一百或一千遍的内容，所以我只能说

* 在 IndexedDB 之上用 JavaScript 实现 SQLite 永远不可能像 WebSQL 解决方案那样快

* 你是不是懒得重写 SQLite 文档，或者是不是像过去时代的 Internet Explorer 一样，做了一些所有成年人都拒绝做的事情……

* 我认为你做出了错误的决定，我希望你（真的！）很快实施 WebSQL 标准，否则它将让你损失许多活跃的开发者和用户。我不知道这是否是你想要的？

2011 年 4 月 19 日中午 12:03
Mats

你好 - 一个瑞典人来电。

我已经从事 Web 开发多年，最近偶然发现了 Web SQL 数据库。它使我可以编写我一直梦寐以求的移动设备应用程序。作为 FireFox 的粉丝，我真的很失望的是我的 Firefox 4 不支持它。

因此，我现在被迫在开发中使用 Chrome。
请重新考虑，尽快开始支持 Web SQL。

来自 Mats 的问候

2011 年 5 月 14 日下午 1:39
Christian R Simms

我没有太多可贡献的，只是我在服务器端应用程序中使用了 sqlite 多年，它真的很可靠。可靠到足以让所有浏览器供应商采用它，这将是一件好事。Hipp 博士在开发它方面做得很好。而且，在 IndexedDB 之上进行的任何客户端分层都不如它快，而且至少需要一年的时间才能变得稳定。

2011 年 5 月 17 日中午 12:35
david karapetyan

你说的这些内容在当前的实现中都没有得到证实。MDC 中记录的内容与 SQL 相比，简直是毫无优雅可言。我看到的只是对 SQL 的一小部分的更命令式和笨拙的实现，而没有声明式 SQL 语法的优雅。另外，是谁天才地想出了分离请求和事务的想法？

2011 年 6 月 25 日上午 0:54
Guido Leenders

我很高兴看到各方正在共同努力，为所有浏览器找到一个适用于中型存储的标准解决方案。这终于允许 HTML 应用程序在脱机状态下工作。并非世界上所有地区目前都拥有 100% 的覆盖率。

我可以想象，目前的 SQL 标准是不够的，语义应该进一步澄清。但据我从大学时代回忆，SQL 是基于集合论的坚实语义。

另一个选择（Indexed DB API）非常底层，我强烈建议我们自己的开发者直接在代码中实现规范，而不是使用很多底层操作，当然还有太多被遗忘的异常处理程序。当然可以对开发者进行培训，但培训需求意味着开发效率降低。

如果 Mozilla 能够重新考虑将 Web SQL 添加到 Firefox，并且各方能够继续完善 Web SQL 标准，我会非常高兴。

2011 年 7 月 10 日上午 4:52
1. Bob H
  
  我不得不赞同，这似乎是在试图让 Web 应用程序中的数据存储尽可能地困难。我刚读完规范，我很惊讶没有人进一步要求 Web 开发人员在 ADA+ASM 中编写数据函数。
  
  Web SQL 似乎是一个更好的解决方案，而 Mozilla 在这里提出的论点从 Web 开发的角度来看根本站不住脚。也许从每天使用 C++ 的人的角度来看，IndexedDB 很好，但大多数 Web 开发人员并没有这样做，这太复杂了。
  
  我同意前面帖子的观点，放弃这项努力。
  
  2011 年 8 月 16 日下午 7:32
[…] 最后我们要介绍的就是 IndexedDB 了，相比其它两个规范，目前只有 Firefox 实现了 IndexedDB（顺便提一下，Mozilla 表示它们永远不会去实现 Web SQL Database），不过 Google 已经表示正在考虑在 Chrome 中加入 IndexDB 支持。 […]

2011 年 8 月 20 日下午 10:18
[…] 最后我们要介绍的就是 IndexedDB 了，相比其他两个规范，目前只有 Firefox 实现了 IndexedDB（顺便提一下，Mozilla 表示它们永远不会去实现 Web SQL Database），不过 Google 已经表示正在考虑在 Chrome 中加入 IndexDB 支持。 […]

2011 年 8 月 24 日上午 2:25
klkl

好决定！

我很感谢您支持 IndexedDB，即使大多数不熟悉 Web 标准流程的开发人员无法理解问题的深度。

2011 年 8 月 26 日下午 4:14
Alek Paunov

各位先生，

复杂的应用程序（例如不断发展的 IDE）需要一个真正的数据库（sqlite 或其他），而不是没有查询语言的键值 API。

很明显哪种解决方案更好
* 使用 WebSQL 轻松模拟 IndexedDB（性能完全相同）
* 任何人都不可能在 IndexedDB 之上模拟 WebSQL - （正如“美学”论点绝对不负责任地所建议的那样）

Mozilla 当前关于此决定的官方立场（这对未来几年 Web 的发展方向具有非常重要的影响力）只是一个可怕的错误，需要纠正。

2011 年 9 月 5 日下午 2:19
Leigh Harrison

这真是一个不幸的决定。

使用 Web SQL DB，编写复杂的离线软件终于成为可能。仔细考虑了 IndexedDB 之后，它甚至没有开始成为一个可行的替代方案，无论是在功能集还是接口方面。在 IndexedDB 之上编写一个第二抽象层来模拟底层的 SQLite 接口是疯狂的，性能损失将是不可接受的。

不将 Firefox 包含在未来项目的目标浏览器中将令人感到遗憾。我真诚地希望 Mozilla 能够重新考虑这个决定。

2011 年 9 月 20 日上午 1:23
Greg

我鼓励大家联系 Mozilla 咨询委员会或 Mozilla 内部人员（甚至 Brendan Eich），对他们决定排除 WebSQL 的决定提出异议；从查看这些帖子来看，他们似乎与开发社区脱节了。

2011 年 9 月 21 日上午 11:25
ed

谢谢您没有提供开发人员需要的功能。您可以在思考和开发更好的解决方案的同时，为我们提供 Web SQL。标准很好，但我们还有工作要做。

2011 年 10 月 24 日上午 4:13
Gary Schaecher

听起来像是两家公司姗姗来迟，想要破坏所有使用 WebSQL 和 SQLite 谋生的开发者辛勤工作和生产力的最后努力！嘘！

2011 年 10 月 30 日下午 7:07
Alon Raskin

绝对是一个糟糕的决定。我们有为 Android、BB 和 iOS 编写的使用 WebSQL 的应用程序。我们现在面临着支持 Windows Phone 的决定，结果发现他们也像 Mozilla 一样走上了 IndexDB 的道路。我们现在该怎么办？我们是否要创建另一个版本的应用程序来支持 Windows Phone？

我们甚至在考虑编写一个 JS 层，它将接收我们的 WebSQL 调用并将其转换为 IndexDB 调用！这样做的效果是保护我们的开发人员免受 IndexDB 的影响！我不知道我们还有其他选择……

2011 年 11 月 8 日上午 12:44
1. Leigh Harrison
  
  抽象层是一个明智的解决方案。
  
  我采用了一种略微不同的抽象方法，因为我的应用程序无论如何都会将后台同步到服务器上的 MySQL 数据库。如果用户运行兼容的浏览器，我们使用 WebSQL；如果用户运行 Firefox 或 Internet Explorer，我们使用 RESTful 服务连接到服务器上的 MySQL 数据库。我研究了 IndexedDB 抽象，但对于我使用的复杂数据库而言，它比通过 Web 获取和设置数据要慢。
  
  为了清楚地说明速度问题所在，我们显示一条消息，建议用户切换到 Chrome 或 Safari 以获得更好的性能。
  
  我不太喜欢这个解决方案，我希望 Firefox 很快会明白并支持 IndexedDB 和 WebSQL。如果他们这样做，微软最终也会加入进来，尽管根据过去的经验，这可能要到 IE13 或者更晚的时候才会发生。
  
  2011 年 11 月 8 日下午 1:37
Eric Kizaki

这就是为什么 M$ 不支持 SQLite 的原因：http://www.microsoft.com/download/en/details.aspx?id=3613

他们有 SQL Server Mobile。

2011 年 11 月 25 日下午 2:08
Eric Kizaki

这是 MS 的 LINQ to SQL 的更新版本。
http://msdn.microsoft.com/en-us/library/hh202860(v=vs.92).aspx

所以说 MS 不支持 Web 数据库是一个站不住脚的论据，因为 MS 在做他们自己的专有事情。没有提到 IndexedDB。如果我开发 MS 应用程序，我会使用这些东西，而不是 IndexedDB。

2011 年 11 月 25 日下午 2:23
Marcelo Cantos

您指的是移动应用程序。这个讨论是关于 Web 的。

2011 年 11 月 26 日上午 2:40
Ramin

Marcelo，这是同一件事。
每个移动设备都有一个浏览器，开发人员可以使用 HTML、CSS、Javascript 和类似 phonegap 的工具来开发软件，这些软件不是针对一个移动操作系统，而是针对所有操作系统，只需更改 CSS 以匹配本机操作系统的外观。或者您可以使用 JQueryMobile 之类的工具。
因此，您可以使用 Web 技术来开发针对所有类型移动操作系统的独立本地软件，这些软件可以在脱机状态下运行（因此它们无法访问具有数据库的 Web 服务器）。您仍然希望为您的软件使用数据库，当然能够使用与发送到 sql 服务器相同的 SQL 查询将其发送到本地 sqlite 数据库非常棒。
作为一名开发人员，您不想学习像 Indexed DB 这样的新东西，您无法在其他任何地方使用它，您想使用 WebSQL，使用您的 SQL 知识，或者您想使用 LINQ，您在使用 C# 进行开发时每天都会使用它。

2011 年 11 月 26 日上午 12:08
1. Marcelo Cantos
  
  @Ramin：如果您和/或 Eric 试图证明微软是虚伪的，我不会反驳。微软是一家非常庞大的公司，在某种程度上，所有大公司都难以公开表达一致的观点。您不会试图争辩说微软不认为平板电脑是未来的方向，仅仅因为 Office 部门一直对平板电脑技术持反对意见，并且拒绝让 Office 在平板电脑设备上可用。
  
  2011 年 11 月 26 日下午 8:04
  1. Ramin
    
    不，每个公司都可以也应该为其自身做最好的事情。实际上，我对 MS 使用 LINQ 提供的功能印象深刻。我只是说，访问移动设备上的数据库非常重要，我认为没有开发人员想要学习 Indexed DB。
    WebSQL 是一件好事，应该得到 Mozilla 和 MS 的支持。
    像大多数其他开发人员一样，我真的无法理解反对 WebSQL 的论据。
    
    2011 年 11 月 27 日上午 10:13
Marcelo Cantos

我想我们是在激烈地同意。:-)

2011 年 11 月 27 日下午 3:27
Waseem

至少可以说令人失望。能够在客户端使用真正的关系数据库引擎，或者至少*拥有这个选项*，将是一件好事。Mozilla 在这件事上彻底搞砸了，我对这个决定感到厌恶。WebSQL 几乎在所有平台上都实现了，Mozilla 的任性让 Web 在离线和本地开发方面倒退了 1-3 年。正是因为这种原因（另见 Firefox 支持的 html5 音频/视频格式），我不再向其他用户推荐 Firefox，而是推荐 Chrome。

2012 年 3 月 22 日上午 7:17
[…] 最后我们要介绍的就是 IndexedDB 了，相比其他两个规范，目前只有 Firefox 实现了 IndexedDB（顺便提一下，Mozilla 表示它们永远不会去实现 Web SQL Database），不过 Google 已经表示正在考虑在 Chrome 中加入 IndexDB 支持。 […]

2012 年 4 月 1 日上午 5:10
[…] https://hacks.mozilla.ac.cn/2010/06/beyond-html5-database-apis-and-the-road-to-indexeddb/ […]

2012 年 5 月 20 日上午 7:16
Freddy May

我同意这里大多数评论者的观点。当然，Mozilla 在添加 IndexedDB 支持方面是正确的——拥有 NoSQL 支持是一件好事。但通过废弃一个在桌面应用程序（尤其是移动应用程序）中运行良好且非常实用的 RDBMS 来吓唬开发社区，这简直是可耻。

2012 年 7 月 16 日上午 4:16
Eric

“在另一篇文章中，我们比较了 IndexedDB 和 Web SQL Database，并注意到前者在语法上比后者更简单”

嗯？在什么世界里？这篇文章表明的情况正好相反！

2012 年 8 月 14 日上午 5:08
John Willis

Mozilla 又犯了一个愚蠢的错误……我真的希望 Chrome 能彻底摧毁 FF 的市场份额，这样像我这样的开发者就不必再迎合 Firefox，Firefox 在这个年代对网页浏览器的意义就像 IE 在上个年代对网页浏览器的意义一样。

2012 年 9 月 21 日下午 12:32
Rene Schickbauer

我是 Maplat Webserver（和框架）的开发者。我目前正在为一个大型项目设计客户端数据存储/缓存。

在评估了文档之后，IndexedDB 在我的项目中根本没有被使用的机会。它无法满足要求，它既不可读，也不快，而且与 ACID 标准相差甚远。它的 API 只是一个“当我长大后，有一天我会成为一个数据库”的垃圾。

另一方面，WebSQL 很好地满足了大多数方面的需求。这可能是我将要使用的方案。

因此，计划如下：要么完全放弃对不支持 WebSQL 的浏览器的支持（反正 Firefox 目前在我业务系统的“市场份额”中不到 1%），要么对那些浏览器不进行客户端数据缓存/存储（这会使它们的速度变慢）。无论哪种方式，我可能都不得不向受影响的用户提供一个最新 Chrome 版本的链接，并建议他们“升级”。

这不是一个理想的解决方案。但在我看来，IndexedDB 对任何严肃的使用来说都太过于破碎和复杂了……

2012 年 10 月 1 日下午 12:59
Nick Vaidyanathan

这可能是一个正确且重要的架构决策。成熟的软件工程界早就认识到，最好是“面向接口编程，而不是面向实现”。

大多数对这个决定感到厌恶的网页开发者可能是“编码员”，而不是工程师或程序员。不幸的是，常见的“网页开发者”无法从纸袋里跳出来，需要 4 个 Drupal/Wordpress 模块才能在一个页面上显示 JSON 内容。别担心他们尖刻的批评，这只是孩子们被告知“不，不要用叉子插电源插座”时的哭喊。（“但它看起来真的很有趣！>:("）

在字符串中传递硬编码的 SQL 查询是错误的。我们在网络上最不需要的就是一大堆客户端 SQL 注入攻击，因为 dumbo.IcopypastaJqueryPlugin().dev 没有对他的输入进行清理，可能导致表格被破坏/用户个人身份信息被盗取。

此外，网络基于开放标准而不是“当前能够完成工作的东西”的想法，是我们都使用不同的程序来实现 HTTP 1.x 和 TCP/IP，而不是 MSIE（或者，对 Mozilla 来说是恰如其分的，Netscape Navigator）的原因。从哲学上讲，这是一个绝佳的决定。

但是评论者也提出了一个很好的观点。拜托，伙计们。现在是 2012 年了。Hibernate 已经存在了十多年。GORM，LINQ to SQL……有很多 ORM/抽象数据映射层的实现。

如果你想自己构建一个基于 NoSQL 哈希映射的数据存储，你应该提供一个基于实体的模型，使用像 GORM 这样的漂亮迭代器和便利魔法方法，而不是像我们使用 ADO.NET 2.0 一样进行底层的游标事务。

2012 年 11 月 8 日下午 5:23
1. Waseem S
  
  拜托，认为开发者水平太差而不能使用 WebSQL 这样的标准的说法根本不相关。我们已经有了 AJAX、客户端脚本和 IndexedDB——如果一个开发者想要造成破坏，破坏就会发生。指向客户端数据的 SQL 语句和修改本地数据存储的 JavaScript 命令一样“危险”。
  
  现在快到 2013 年了；web 应用已经走过了漫长的道路，并且已经成熟。用保护孩子的态度对待网页开发者只会阻碍进步。
  
  2012 年 12 月 3 日下午 9:14
2. ArchE
  
  Nick，这太过于注重架构上的讨论，以至于你看不到森林。
  
  就像这样
  学者：“我们种植了红色的甜苹果，亲爱的主人。每个人都喜欢它。”
  主人：“亲爱的学者，那不好。苹果必须是蓝色的。”
  学者：“但蓝色的苹果有毒。”
  主人：“没关系，亲爱的学者，这样就没有人会吃了。最终，我们就会有蓝色的苹果。”
  
  2012 年 12 月 4 日下午 1:36
ArchE

总的来说，我强烈反对。通过这个决定，你限制了选择自由。

从哲学角度来看，这很糟糕！
给我们选择自由！

1. SQL 关系引擎从哲学角度来看与 NoSQL 处于同一级别。NoSQL 使用 JavaScript 来访问对象，而 RDBMS 使用 SQL。
有什么区别吗？……NoSQL 中没有真正的 ORM。
2. SQLLite 是 ANSI SQL，而 ANSI SQL 是标准。
3. 美学——代码统一？好吧，这并不是真正的论点，但我理解。
4. SQLLite 的变化？拜托，这只是一个补充论点，你总是能够保持稳定的构建。

你应该照顾开发者，而不是告诉他们如何工作。这不是好的做法，正如我所说，你限制了选择自由。

此外，你现在已经将使用 WebSQL 且可用于移动设备的应用程序从 FF 中剔除了。因为 Chrome、Safari 和 IE 支持 WebSQL。

2012 年 11 月 13 日下午 11:57
1. Robert Nyman
  
  说到 Internet Explorer，它从未支持过 WebSQL。当前的支持情况在 caniuse 网站上列出。
  
  此外，WebSQL 规范已被弃用。
  
  2012 年 11 月 14 日上午 1:30
  1. ArchE
    
    被弃用，对吧……根据 W3C 的说法。
    规范陷入了僵局：所有感兴趣的实现者都使用了相同的 SQL 后端（Sqlite），但我们需要多个独立的实现才能沿着标准化道路前进。
    
    从这个角度来看，我真的不明白。多个实现？
    许多项目已经使用 WebSQL 或持久性层。
    为什么不支持像 SQLLite 这样简单的实现？
    
    在我看来，似乎对 SQLLite 有强烈的厌恶感 :)
    
    2012 年 11 月 14 日上午 2:56
ArchE

你可以在这里找到关于为什么 SQL Lite 从哲学角度来看不是坏主意的其他论点 http://www.html5rocks.com/en/tutorials/webdatabase/websql-indexeddb/

2012 年 11 月 14 日上午 1:07
Richard Collins

我对在离线 web 应用中使用一个像样的数据库感到非常兴奋，我正在开始开发这个应用。然后，我发现了 Mozilla 不支持 WebSQL 的这个疯狂决定。现在我面临着这样一个选择：要么使用 IndexedDB 显著增加开发时间，要么创建一个只支持 Chrome/Safari 的应用程序。

虽然我理解这种推理，但它似乎过于狭隘。让我们支持一项好技术。Sqlite 是公共领域的。如果在将来出现不兼容性，社区会把它分叉出去。

2012 年 12 月 3 日下午 12:59
1. ArchE
  
  点赞。
  看来，社区对这个决定非常失望。
  
  虽然我目前正在开发一个 WebSQL 应用程序，但我决定不支持 FF。
  
  我坚信 FF 的开发者会改变这个决定。希望不会太晚。
  
  2012 年 12 月 3 日下午 11:48
Waseem S

Firefox (Mozilla) 通过这种决定，让人觉得他们是固执己见的清教徒，他们不会理会其他人，因为他们知道什么对每个人最好。除了破坏客户端数据存储之外，Firefox 还是唯一一个无法通过 HTML5 标签播放用无处不在的 MP3 格式编码的文件的主流浏览器。任何创建跨平台媒体解决方案的尝试都必须包含将所有媒体重新编码为 ogg 或其他格式，这会使编码时间、媒体存储需求和成本翻倍。他们没有让网络更容易被所有人访问，而是设置了障碍，特别是对小型组织而言。
他们说 MP3 是一种不应该使用的专有格式，这种说法很可笑，因为他们支持 GIF。.

2012 年 12 月 3 日下午 9:09
Sebastian Baltes

Mozilla 在这件事上犯了严重的错误。

我们正在开发一个基于 WebSQL 和 PhoneGap 的中等规模的 HTML5 应用程序，在 JavaScript 中使用 SQL 真是太棒了！我们在所有移动平台上都有它（在 Win8 中通过 SQLite 插件）。即使在中等规模的应用程序中，关系模型也具有很多优势：强大的查询语言、事务、速度和稳固性。而且我们有一些大型的 SQL 查询——用 IndexedDB 手动完成这些操作将是一场噩梦。

十多年前，面向对象的数据库是炒作的焦点。什么存活下来了？SQL。然后是 NoSQL……它很好，而且有自己的利基市场，但大多数人仍然使用关系数据库。猜猜看，十年后什么会占主导地位？

你们的 IndexedDB 对于最简单的用例来说可能很不错，但对于这些用例，我们已经有 localStorage 了。复杂用例无法由你们不成熟的设计婴儿来处理。

而且，你们 Mozilla 的人为什么要设计自己的持久化标准？请向我解释一下：为什么你们没有选择 MongoDB 作为例子？因为它不是标准？闻起来像某种自负，就像“哦，我们太聪明了，我们拥有所有这些钱，却不知道如何花”的态度。你猜怎么着？沿着这条路走下去，十年后 Firefox 将变得无关紧要，但我们仍然会在浏览器中使用 SQL。

2013 年 1 月 17 日上午 10:06
Sergei

我同意，结构化索引存储更适合作为 Web 平台的基础。最好是在原始结构化存储之上拥有 Web SQL 存储。我同意 Mozilla 关于依赖 SQLite 语法的观点，这是一个不好的做法。但是，IndexedDB 的 API 太糟糕了。看看 https://hacks.mozilla.ac.cn/2010/06/comparing-indexeddb-and-webdatabase/ 中的例子 4。
这根本不是前进的方向。

2013 年 2 月 5 日上午 7:19
Vikash Madhow

任何说 IndexedDB 比 WebSQL 更好的人都不知道自己在说什么。

除了最简单的用例之外，IndexedDB 永远无法让网页浏览器成为一个平台，在该平台上我们可以为 web 应用提供有用的离线模式，以应对网络连接中断的情况。我建议我们集体转向 Chrome，并建议所有人也这样做。就我个人而言，我需要像 WebSQL 这样的东西来构建我正在开发的应用，因此 Firefox 不在我的支持浏览器列表中。

2013 年 3 月 8 日下午 11:14

本文的评论已关闭。

Hacks

作者：Arun Ranganathan

SQL？哪种 SQL？

SQLite 的优点和缺陷

美学和 Web 开发者

链接

关于Arun Ranganathan

117 条评论

超越 HTML5：数据库 API 和 IndexedDB 之路

作者：Arun Ranganathan

SQL？哪种 SQL？

SQLite 的优点和缺陷

美学和 Web 开发者

链接

关于Arun Ranganathan

发现 Web 开发的优秀资源

谢谢！请检查您的收件箱以确认您的订阅。