考虑到只有WebSQL支持您列出的所有三个需求，您的选择不应该很简单吗？您不了解Safari或Android的开发路线图，所以请使用您现有的内容。

好吧，就像所有的计算一样，游戏是“抽象”的。

如果您能够在SQL存储和键/值存储上找到一个合适的层，那么，理想情况下，您可以与问题隔离，并可以在特定浏览器上支持适当的实现。如果您的数据模型和访问模式不符合最低公分母（即k/v存储），那么这基本上解决了您的问题。

如果你可以使用任何一个商店，那么就创建一个像样的访问层，并从这个方向解决问题。

请注意，仅仅因为您在后端有一个k/v存储并不意味着您必须将数据建模为仅一个k/v模型。从本质上讲，后台的所有数据库都是一个k/v存储。如果你没有大量的数据，你可以做很多事情。对于大量数据，您可能不得不跳过的障碍可能会使您的性能下降，而对于少量数据，您很可能看不到这一点。一切取决于情况。

我将在2016年（在您提出此问题5年后）对此进行回复，并回答与对WebSQL的弃用仍然存在.另一方面，IndexedDB，得到了所有主要浏览器供应商的支持。

因此，对于任何可能在这里面临同样决定的人来说，选择IndexedDB。

然而，正如这里其他人所暗示的那样，这样的决定并不一定必须做出；人们可以简单地选择（或制作）一个库，该库利用客户端机器上可用的任何数据库。

BakedGoods与这里已经建议的这些库有几个不同之处；最重要的是，它允许明确指定要使用的存储类型，从而允许开发人员在决策过程中引入其他因素（如性能特征）。

有了它，在支持的任何数据库类型中执行存储操作都是一个。。。

…为两种数据库类型指定适当的操作选项和等效配置：

//If the operation is a set(), and the referenced structures 
//don t exist, they will be created automatically.

var webSQLOptionsObj = {
    databaseName: "Example_DB",
    databaseDisplayName: "Example DB",
    databaseVersion: "",
    estimatedDatabaseSize: 1024 * 1024,
    tableData: {
        name: "Main",
        keyColumnName: "lastName",
        columnDefinitions: "(lastName TEXT PRIMARY KEY, firstName TEXT)"
    }, 
    tableIndexDataArray: [name: "First_Name_Index", columnNames: "(firstName)"]
};

var indexedDBOptionsObj = {
    databaseName: "Example_DB",
    databaseVersion: 1,
    objectStoreData: {
        name: "Main",
        keyPath: lastName,
        autoIncrement: false
    },
    objectStoreIndexDataArray: [
        {name: "First_Name_Index", keyPath: "firstName", unique: false, multiEntry: false}
    ],
};

var optionsObj = {
    conductDisjointly: false, 
    webSQL: webSQLOptionsObj, 
    indexedDB: indexedDBOptionsObj
};

…并进行操作：

bakedGoods.set({
    data: [
        {value: {lastName: "Obama", firstName: "Barack"}}, 
        {value: {lastName: "Biden", firstName: "Joe"}}
    ],
    storageTypes: ["indexedDB", "webSQL"],
    options: optionsObj,
    complete: function(byStorageTypeStoredItemRangeDataObj, byStorageTypeErrorObj){}
});

其简单的界面和无与伦比的存储设施支持是以缺乏对某些存储设施特定配置的支持为代价的。例如，它不支持在具有多列主键的WebSQL表中执行存储操作。

因此，如果你大量使用这些类型的功能，你可能想另谋高就。

哦，为了完全透明，BakedGoods由您的公司真正维护：）。

我的建议是使用IndexDB，因为有IndexDB Polyfill可用。

所有支持WebSQL的浏览器都可以支持IndexDB API采用这种方式。反之则很难实现，因此，如果您想访问所有了解某些DB API的浏览器，IndexDB是目前的最佳选择。

注意：即使这个问题已经过时了，它仍然是相关的，所以我认为这个问题的答案值得更新。很抱歉使用仅链接的解决方案，所以我只添加了指向通常持久的目的地的链接：W3C和GitHub

您的数据库需求是否远远超出密钥/值存储？如果没有，我已经找到了许多用于基于本地浏览器的数据库抽象的javascript包。其中一个包是jStore：

http://code.google.com/p/jquery-jstore/

我最近用它来添加本地密钥/值存储。它有很好的文档记录，集成时间可以忽略不计——它通过其API支持一系列存储后端，包括闪存本地存储。

CouchDB是一个很好的解决方案——对于与您的问题不太一致的问题。查看couchphone mobile。不适用于严格意义上的网络应用程序，但如果您对规范有一定的灵活性，它可能会为您提供一个可以运行的数据库基础。

根据您对iOS上Safari的给定要求，除了WebSQL，别无选择。WebSQL在Opera和Blackberry等其他移动浏览器中也受支持。我不认为他们会删除对WebSQL的支持，即使他们有IndexedDB。不知怎的，它们是互补的。

另一方面，在浏览器存储战争中，IndexedDB赢得了胜利。IE和FF将仅具有IndexedDB。具有讽刺意味的是，FF在Sqlite之上实现了IndexedDB。

我想说的是IndexedDB不仅仅是一个键值存储。它有索引和事务。仅这两者就提供了SQL查询的几乎所有功能，包括联接、条件查询和排序。由于它的异步API，一开始并不明显。

IndexedDB的性能优于WebSQL。它更安全。对于javascript用例来说，它更灵活。最后，它更易于使用。

为了说明这种情况，我将使用我的库，但您可以直接使用IndexedDB API：

people = {
  name:  Foo Bar ,
  email:  foo@bar.com 
  hobby: [ camping ,  swimming ]
};

var req = db.keys( people ,  hobby , IDBKeyRange.only( camping ));
req.done(function(campers) {
  db.keys( people , campers,  name ).done(function(names) {
     console.log(names);
  });
});

var q1 = new ydn.db.Iterator( friendship ,  friend_list , IDBKeyRange.only(me));
var q2 = new dn.db.Iterator( friendship ,  friend_list , IDBKeyRange.only(other_guy));
// if location is not indexed, a filtered value query is used.
var q3 = new ydn.db.Iterator( people , new ydn.db.Expression([ "location" , " Singapore ",  = ]));
// if location is indexed, an index query is used.
// var q3 = new ydn.db.Iterator( people ,  location , IDBKeyRange.only( Singapore ));
var current_loop = 2; // start from inner loop
var join_algo = function(keys, index_keys) {
  var advancement = [];
  advancement[keys.length - 1] = null;
  var has_adv = false;
  for (var i = 0; i < keys.length; i++) {
    if (!goog.isDef(keys[i])) {
      // completed iterator
      if (i != 0) {
        advancement[i] = false; // request to restart the iteration
        advancement[i - 1] = true; // advance outer iterator
        current_loop = i - 1;
      } // i == 0 means we are done.
    has_adv = true;
    break;
    }
  }
  if (!has_adv) {
    // continue looping current
    advancement[current_loop] = true;
  }
  return advancement;
}
var result = db.scan([q3, q1, q2], join_algo);
result.done(function(keys, index_keys, values) {
  console.log(values); // should get desire list of friends 
});