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

проблема:

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

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

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

• быстро (ответы до 2 секунд)


• потенциально выполнять соединения и иметь отношения с другими таблицами, способными запрашивать базу данных


• выберите данные в пределах определенного диапазона или критериев, например, по координате x & y на основе GPS чтение.

варианты:

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

штраф для небольших объемов данных

плюсы:

• для более чем 10 000 строк даже на хай энд аппарат браузер
  медленно ползти.


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


• ограничения с количеством хранения, которое может быть сохранено

база данных Web SQL:

• отвечает требованиям.


• быстро выполнить запрос на 250 000 строк (1-2secs)


• можно создавать сложные запросы, объединения и т. д.


• поддерживается Safari, Android и Opera, поэтому будет работать на iOS и Android устройств

плюсы:

• устарел по состоянию на ноябрь 2010 года


• недостаток безопасности с кросс-атак. Не очень проблема, так как мы не будем на общем хостинге

IndexedDB:

хранилище объектов ключа/значения аналогично локальному хранилищу, за исключением индексов.

плюсы:

• медленно выполнить запрос на 200,000 строки (15-18secs)


• не удается выполнить сложные запросы


• не могу сделать соединения с другими таблицами


• не поддерживается основными телефонными или планшетными устройствами, например iPad / Android


• стандарт не полностью

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

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

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

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




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




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

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

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

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