HTML5 IndexedDB，Web SQL数据库和浏览器大战

6 回答

• 5

  我的建议是 go for IndexDB ，因为有一个IndexDB Polyfill可用 .

  支持WebSQL的所有浏览器都可以通过这种方式支持IndexDB API . 反过来非常难以实现，因此如果您想要访问所有了解某些DB API的浏览器，IndexDB是当今最好的选择 .

  ---

  注意：即使这个问题很老，它仍然是相关的，所以我认为这个问题的答案值得更新 . 对于仅链接解决方案感到抱歉，所以我只添加了通常持久目的地的链接：W3C和GitHub

  回复于 2024-04-19T23:30:00+08:00
• 6

  根据您在iOS上对Safari的要求，除了WebSQL之外别无选择 . 其他移动浏览器（如Opera和Opera）支持WebSQL黑莓 . 即使他们有IndexedDB，我也不认为他们会删除WebSQL支持 . 不知何故，他们是互补的 .

  另一方面，在浏览器存储战争中，IndexedDB获胜 . IE和FF只有IndexedDB . 讽刺的是，FF在Sqlite之上实现了IndexedDB .

  我想说的是IndexedDB不仅仅是关键值存储 . 它有索引和交易 . 这些只有两个几乎构成SQL查询的所有功能，包括连接，条件和排序 . 起初并不明显，因为它的异步API .

  IndexedDB的性能优于WebSQL . 它更安全 . 它对javascript用例更灵活 . 最后它更容易使用 .

  为了说明这种情况，我将使用my library中的sudo代码，但您可以直接使用IndexedDB API：

  'people'商店有索引字段'name'和list indexed字段'hobby' . 在JSON中，

  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);
    });
  });
  

  关于这段代码的有趣之处在于没有涉及序列化 . 因此它非常快 .

  以下示例说明了友谊图查询 . friendship 对象库只有一个列出的索引字段 friend_list . 它使用人物对象存储键作为外线主键 . people 对象库有很多属性，其中有 location 字段 . 该查询是查找知道 me 和 other_guy 且位于'Singapore'的朋友列表 .

  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 
  });
  

  此连接查询再次只是键扫描，因此非常快 . 默认情况下 scan 使用sorted-merge算法来查找匹配的键，但这里显示了朴素的嵌套循环连接算法 . 因此表连接是可能的，但您必须编写连接算法 . 但是像Zigzag merge这样的新算法比使用Sqlite更快，因为所有输入都是排序的，游标可以很好地进步，更重要的是加入过程可以利用不在数据库中的外部知识 . 使用SQL，连接操作是不透明的 .

  除了IndexedDB之外，还可以使用流式传输和map / reduce处理等技术 .

  回复于 2024-04-19T23:30:00+08:00
• 5

  我在2016年回答这个问题（在您提出这个问题后的5年）以及有关deprecation of WebSQL still stands的所有内容 . 另一方面，IndexedDB，enjoys the support of all of the major browser vendors .

  所以对于那些可能发现自己面临相同决策的人来说，请使用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由你的真正维护:) .

  回复于 2024-04-19T23:30:00+08:00
• 14

  您的数据库是否需要显着超出键/值存储？如果没有，我发现了一些基于浏览器的数据库抽象的javascript包 . 一个这样的包是jStore：

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

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

  CouchDB是一个很好的解决方案 - 对于一个与你的问题不完全相同的问题 . 看看couchone mobile . 不严格'web apps'但它可能提供您可以运行的数据库基础，如果您对规范有一定的灵活性 .

  回复于 2024-04-19T23:30:00+08:00
• 24

  考虑到只有WebSQL支持您列出的所有三个要求，您的选择不应该简单吗？您无法深入了解Safari或Android的开发路线图，因此请使用您可用的内容 .

  回复于 2024-04-19T23:30:00+08:00
• 6

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

  如果您能够提供适用于SQL存储和键/值存储的适当层，那么理想情况下，您可以与问题隔离并支持特定浏览器上的相应实现 . 如果您的数据模型和访问模式不适合最低公分母（即k / v商店），那么这就解决了您的问题 .

  如果您可以使用任一商店，那么就可以在一个合适的访问层上工作，并从该方向处理问题 .

  记住，仅仅因为你在后端有一个k / v商店并不意味着你必须将你的数据建模为只有一个k / v模型 . 基本上所有DB都在后端是一个k / v商店 . 如果您没有疯狂的数据量，您可以做很多事情 . 对于大量数据，您可能需要跳过的箍可能会花费您的性能，而您可能无法通过较少的数据看到这些数据 . 一切都取决于

  回复于 2024-04-19T23:30:00+08:00