HTML5 IndexedDB, база данных веб-SQL и браузерные войны

Я начинаю разработку веб-приложения с автономными требованиями к хранению базы данных. Короче говоря, приложение должно быть в состоянии работать на:

  • один из основных настольных браузеров, Chrome preferred
  • Safari на iOS
  • родной браузер Android (на основе V8 и WebKit)

Итак, вопрос в том, какую технологию выбрать: IndexedDB или Web SQL Database?

Что касается базы данных Web SQL, с одной стороны, она готова для использования в любом из вышеперечисленных сценариев. С другой стороны, Mozilla заявила, что Firefox никогда не будет реализовывать ее, и в соответствии с HTML5 рабочий проект спецификация зашла в тупик:

эта спецификация зашла в тупик: все заинтересованные разработчики использовали один и тот же SQL-сервер (Sqlite), но нам нужно несколько независимых реализаций для продвижения по пути стандартизации. Пока другой исполнитель не заинтересован в реализации эта спецификация, описание диалекта SQL было оставлено как просто ссылка на Sqlite, что неприемлемо для стандарта. Если вы являетесь разработчиком, заинтересованным в реализации независимого бэкэнда SQL, обратитесь к редактору, чтобы он мог написать спецификацию для диалекта, что позволит этой спецификации двигаться вперед.

IndexedDB является альтернативой, поддерживаемой Mozilla, но она будет доступна только в Firefox 4. Microsoft заинтересована и Chrome поддержит его также. Я ничего не знаю о планах Apple относительно IndexedDB.

Я лично склонен выбирать веб-базу данных SQL, но только потому, что я привык к SQLite, мне нравится сила и выразительность SQL, и я понимаю реляционную модель. Для меня IndexedDB-это неопределенность.

тем не менее, я боюсь делать ставки не на ту лошадь. Можно ли предположить, что поддержка базы данных Web SQL будет продолжать существовать, даже если IndexedDB станет стандарт?

(примечание по CouchDB: вы также видите его в качестве альтернативы?)

6 ответов


учитывая, что только WebSQL поддерживает все три требования, которые вы перечислили, не должен ли ваш выбор быть простым? У вас нет понимания дорожной карты развития для Safari или Android, поэтому используйте то, что у вас есть.


Ну, как и со всеми вычислениями, игра является "абстракцией".

Если вы можете придумать адекватный слой, который работает как на хранилище SQL, так и на хранилище ключей/значений, то в идеале вы изолированы от проблемы и можете поддерживать соответствующую реализацию в конкретном браузере. Если ваша модель данных и шаблоны доступа не соответствуют наименьшему общему знаменателю (т. е. магазину k/v), то это в значительной степени решает вашу проблему прямо там.

Если вы можете использовать либо храните, затем работайте над достойным уровнем доступа и подходите к проблеме с этого направления.

ум, только потому, что у вас есть магазин k/v на задней панели, не означает, что вы должны моделировать свои данные только как модель k/V. По сути, все БД на бэкэнде-это магазин k/V. Если у вас нет безумного количества данных, вы можете многое сделать. С большим количеством данных обручи, которые вам, возможно, придется прыгать, могут стоить вам производительности, которую вы не увидите с меньшим количеством данных. Все зависит от обстоятельств.


ваша база данных нуждается значительно за пределами хранилища ключей/значений? Если нет, я нашел несколько пакетов javascript для локальной абстракции базы данных на основе браузера. Одним из таких пакетов является jStore:

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

недавно я использовал его для добавления локального хранилища ключей / значений. Это хорошо документировано, и время интеграции было незначительным - он поддерживает массив бэкэндов хранения, включая локальное хранилище flash, через его ПРИКЛАДНОЙ ПРОГРАММНЫЙ ИНТЕРФЕЙС.

CouchDB-отличное решение для проблемы, которая не совсем согласуется с вашей. Проверьте couchone mobile. Не для строго "веб-приложений", но он может обеспечить базу данных, с которой вы можете работать, если у вас есть некоторая гибкость со спецификацией.


С вашим данным требованием Safari на iOS нет альтернативы, кроме WebSQL. WebSQL поддерживается в других мобильных браузерах, таких как Opera и Blackberry. Я не думаю, что они удалят поддержку WebSQL, даже если у них есть IndexedDB. Каким-то образом они дополняют друг друга.

С другой стороны, на войне хранения браузера, IndexedDB win for good. IE и FF будут иметь только IndexedDB. Ироничный факт заключается в том, что FF реализует IndexedDB поверх Sqlite.

что я хотел бы скажем, IndexedDB-это больше, чем просто хранилище ключевых значений. Он имеет индекс и транзакцию. Эти только два делают почти все функции SQL-запроса, включая join, conditional и sorting. Сначала это не очевидно из-за его асинхронного API.

производительность IndexedDB лучше, чем WebSQL. Это более безопасно. Он более гибок для случая использования javascript. Наконец, он более прост в использовании.

чтобы проиллюстрировать случай, я буду использовать код sudo из мой библиотека, но вы можете использовать IndexedDB API напрямую:

в магазине "люди" есть индексное поле " Имя "и индексированное поле "хобби". В 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 в качестве внешнего первичного ключа. people object store имеет множество атрибутов, среди которых


моя рекомендация -перейти на IndexDB, потому что Полифилл IndexDB доступен.

все браузеры, поддерживающие WebSQL, могут поддерживать IndexDB API этот путь. Другой способ будет очень сложно реализовать, поэтому, если вы хотите достичь всех браузеров, которые знают о некоторых API DB, IndexDB-лучший выбор сегодня.


Примечание: даже если этот вопрос старый, он по-прежнему актуален, поэтому я думаю, ответы на этот вопрос заслуживают обновления. И извините за решение только для ссылок, поэтому я добавил Только ссылки на обычно длительные направления: W3C и GitHub


я отвечаю на это в 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 поддерживается вашим покорным слугой :).