Разработка автономного хранилища HTML5 для iOS/Android в 2011 году

Проблема:

Мне нужно решение agnostic (например, HTML5) для хранения и запроса 250 000 + строк данных в автономном режиме на устройстве типа телефона или планшета (например, iOS/Android). Идея заключается в том, что у меня есть люди, работающие в отдаленных районах без какого-либо сотового обмена данными, и им нужно запускать запросы по этим данным и редактировать их в автономном режиме. Частично он будет основан на геолокации, поэтому, если в области, в которой они находятся (используется GPS), есть активы, и они будут отображать эти активы и позволять им редактировать. Когда они возвращаются в офис, они могут синхронизировать данные с офисным сервером.

Причина, по которой я приближаюсь к этому с точки зрения веб-стандартов, заключается в том, чтобы сэкономить деньги и время, написав его один раз в HTML5, а затем он работает на нескольких платформах, а не дважды записывает его в Objective C и Java. Кроме того, если вы напишете что-то, что агностик платформы, то вы не заперты и не спускаетесь с корабля, когда все переходят к более новому. У нас было аналогичное приложение, написанное для Windows Mobile 5, теперь оно бесполезно, поскольку эта платформа мертва.

В автономной базе данных на устройстве должно быть:

• быстрый (ответы менее 2 секунд)
• потенциально выполняет объединения и имеет отношения с другими таблицами, способными запрашивать базу данных
• выберите данные в определенном диапазоне или критериях, например. по координатам x и y на основе показаний GPS.

Параметры:

локальное хранилище HTML5:

Хорошо для небольших объемов данных < 5000 ключей/значений, вы можете даже хранить в нем массивы/объекты, если вы преобразуете их в JSON.

Минусы:

• Для более чем 10 000 строк даже на высокопроизводительной машине браузер будет медленное сканирование.
• Невозможно выполнить сложные запросы на данные, чтобы вытащить нужные вам данные, поскольку вам нужно перебирать все хранилище и вручную искать его.
• Ограничения с объемом хранения, который можно сохранить

База данных веб-SQL:

• Соответствует требованиям.
• Быстрый запуск запроса на 250 000 строк (1-2 сек.)
• Может создавать сложные запросы, объединения и т.д.
• Поддерживается Safari, Android и Opera, поэтому будет работать на устройствах iOS и Android.

Минусы:

• Устаревший с ноября 2010 года
• Недостаток безопасности с межсетевыми атаками. На самом деле проблема не в том, что мы не будем на хостинге.

IndexedDB:

Хранилище ключей/значений, похожее на локальное хранилище, за исключением индексов.

Минусы:

• Медленный запуск запроса на 200 000 строк (15-18 секунд)
• Невозможно выполнить сложные запросы
• Невозможно выполнить объединение с другими таблицами.
• Не поддерживается основными устройствами телефона или планшета, например. IPad/Android
• Стандарт не полностью

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

Я не уверен, что Mozilla и Microsoft получили стандартную базу данных веб-SQL, и они не позволяют W3C. Предположительно между ними у них 77% рынка настольных браузеров. На продвинутых мобильных устройствах Mozilla и Microsoft имеют почти нулевое влияние, поскольку Safari, Opera и Android имеют более 90% доли рынка. Как Mozilla и Microsoft могут диктовать, какой стандарт следует использовать на мобильном рынке, где автономное хранилище, скорее всего, будет использоваться, не имеет никакого смысла.

В комментариях от Mozilla о том, почему они хотели пойти с IndexedDB, в основном, относятся к "эстетике разработчика", и им не нравится идея запуска SQL в JavaScript. Я не покупаю его.

• В настоящее время предлагаемый стандарт уступает, и чрезвычайно простая реализация NoSQL медленна и даже не поддерживает дополнительные функции, которые нужны людям в базе данных. Существует много шаблонов кода для создания базы данных и получения данных, но они утверждают, что люди напишут несколько хороших библиотек абстракции поверх нее, что обеспечит более сложные функции. По состоянию на октябрь 2011 года их нигде не видно.

• Они устарели существующий стандарт веб-SQL, который фактически работает и реализован в основных браузерах для мобильных/планшетов. В то время как их "новый" и "лучший" стандарты недоступны в основных мобильных браузерах.

• Что мы, как разработчики, должны использовать в течение следующих 3-5 лет, когда спецификация IndexedDB может стать стандартизированной, иметь больше функций, реализованных в основных браузерах для мобильных/планшетов, и там есть некоторые приятные библиотеки, чтобы упростить работу?

W3C должен поддерживать параллельный стандарт базы данных Web SQL и просто исправлять проблемы. Он уже поддерживает основные мобильные платформы, и он работает очень хорошо. Тот факт, что Mozilla и Microsoft в качестве двух игроков с большинством настольных браузеров смогли получить этот стандартный отказ, довольно сомнительны и могут рассматриваться как попытка помешать продвижению на мобильных веб-платформах, пока они не смогут догнать и предложить конкурирующие решения для iOS/Safari и Android.

В заключение у кого-нибудь есть решение моей проблемы, которая будет работать для iOS/Android для телефонных/планшетных устройств. Возможно, хороший API-интерфейс обертки, который может использовать несколько реализаций баз данных в фоновом режиме с возможностью запросов, и позволяет вам выбрать, какая из баз данных имеет приоритет. Я видел такие вещи, как lawnchair, но я уверен, что он позволяет использовать локальное хранилище по умолчанию и возвращается к другим. Я думаю, я предпочел бы, чтобы он использовал веб-SQL (по умолчанию), а затем более медленные параметры.

Любая помощь для решения, очень ценимого, спасибо!

Ответы

git clone https://github.com/brianleroux/lawnchair.git  
cd lawnchair  
cat src/Lawnchair.js src/adapters/indexed-db.js src/adapters/webkit-sqlite.js src/adapters/gears-sqlite.js > my_lawnchair.js