Кеширование справочников в формах

[SiZE]

Пользователь в браузере заходит на сайт, открывает различные диалоговые окна с формами, выбирает данные из выпадающих списков и отправляет значения на сервер. Общий объем справочников подгружаемых из базы в формы может быть до 100 Мб.

Что лучше использовать для локального кеширования данных в javascript? При этом конечно необходимо держать справочники актуальными. И желательно чтобы это работало не только в ФФ, но и Опера, Хром, Сафари (планируется использование айпэдов). Еще важна скорость подстановки данных в форму.

Вот что приходит в голову чтобы избавится от необходимости гонять по 30-100 метров каждый раз:
1. Каждый справочник выдается как js файл. Вопрос кешировать в таком случае как обычно заголовками или засунуть в AppCache? Не знаю на сколько это практично все.
2. Данные кешируются в WebStorage, но тут опять же ограничение на объем хранимой информации и не известно как поддерживают это все мобильные устройства.

Какие будут мысли и варианты?

 

[Adelf]

100Мб - это бред.
Совет - поменять интерфейс, чтобы не было необходимости гонять столько данных.

 

[SiZE]

100Мб - это бред. Совет - поменять интерфейс, чтобы не было необходимости гонять столько данных.

Согласен, что каждый раз загружать сайт под 100мб это бред. Поэтому и необходимо закешировать эти 100мб и не гонять их больше. Спрашиваю совета "как?".

 

[Adelf]

SiZE
Да не выдержит у тебя браузер мобильных сафари столько держать "в уме". Да и обычные будут с трудом переваривать. Я не верю что нельзя так поменять интерфейс, чтобы избежать такой тьмы инфы на клиенте. Проблема тут не в кешировании а в перегруженности самого клиента.

 

[SiZE]

Для понимания. Оператор работающий с системой, заполняет часть данных переданных по телефону, часть данных он выбирает из справочников. На это ему отводится 30 секунд. Поэтому все справочники должны лежать в локальном кеше и загружаться полностью только при первом обращении к сайту. Это увеличит скорость доступа к ним и скорость загрузки данных в форму не будет зависеть от скорости связи с интернетом. Иногда справочники актуализируются и должны соответственно обновляться в локальном кеше.

 

[SiZE]

SiZE
Да не выдержит у тебя браузер мобильных сафари столько держать "в уме". Да и обычные будут с трудом переваривать. Я не верю что нельзя так поменять интерфейс, чтобы избежать такой тьмы инфы на клиенте. Проблема тут не в кешировании а в перегруженности самого клиента.

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

 

[Adelf]

гугл держит пентабайтные наборы инфы и достает их в доли секунды. Я бы делал также.
Если уж критична скорость инета(точнее есть желание обеспечить работу в плохом инете) - отдельный клиент с кешем инфы.
Яваскрипты. Можно конечно... AppCache. Но, подозреваю, о мобильных можно забыть.

а при обращении к форме доставать из него только нужные ей справочники?

Это означает что в определенный момент времени нужны только некоторые данные? Не все 100Мб?

 

[Beavis]

интересно, сколько терабайт памяти сожрет файрфокс, если в нём это всё открыть

 

[Adelf]

Beavis
ну полгига слопает я думаю.

 

[С.]

Если по-хорошему, то тут нужен специализированный клиент. А если "слепила из того, что было", то вижу локальный сервер (типа Денвера), где будут лежать периодически обновляемые справочники.

 

[Фанат]

интересно, мне одному приходит в голову мысль об ультрамодной технологии "аякс"?

На это ему отводится 30 секунд.

а. не увидел уточнение про очередную спортивную задачу "сварите суп на роту солдат имея из продуктов пустой стакан и бутылку водки".

Я правильно понимаю, что весь этот чемпионат по скоростному заполнению форм просто обязательно должен работать в стандартном браузере и на медленном интернете?

 

[С.]

интересно, мне одному приходит в голову мысль об ультрамодной технологии "аякс"?

И как аякс решит проблему 100 мег? Да пусть 10 мег? Ну даже 1мег на запрос?

 

[Adelf]

С.
Я опять таки повторю. У гугла инфы на кучу пентабайт. Но нужное он отдает мгновенно.
Тут тоже самое. Оператору не нужны все 100 метров. Ему нужно совсем немного. И ессно - переделать интерфейс, аякс.. и т.д. и т.п. Я бы так скорее всего сделал.

 

[weregod]

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

 

[lagoff]

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

Самый нормальный и правильный вариант.

С js-файлом на справочник появляется гемор с обработкой ситуации, когда справочник обновился в рабочее время, когда у оператора все закешировано.

Про Web Storage - забудьте из-за объема. Пруф в гугле.

А вообще, в идеале, я вижу тут Flex, а не HTML/JS - решает все ваши проблемы одним махом.

ЗЫ Очень хочется посмотреть на этот мега-интерфейс.

 

[С.]

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

А я имел в виду, что 100 мег набирается не из миллиона справочников по 1кб каждый, а все-таки более счетное их количество, но каждый значительно тяжелее. Да и даже короткий запрос отнюдь не со коростью света делается. Аякс на столько очевидный вариант, что если ТС его сразу не упомянул, то наверное он не подошел. Однако давайте дождемся разъяснений ТС.

 

[SiZE]

Почитал все мнения, вы рассуждаете верно конечно, с одной стороны. Но всегда есть и другая сторона

У гугла же запатентованная файловая система, крутой дата центр, операторы себе позволить такого не могут. Максимум что я могу, поставить каждому оператору сервер, который будет синхронизироваться периодически с удаленным сервером.

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

Автокоплит из аякс запросов не совсем подходит, т.к. справочник может содержать 10 000 наименований, оператор их все может и не помнить, как они точно называются. Может кто знает как это обыграть? Я нет Пока он будет перебирать возможные варианты уйдет время. Возможно дополнить загруженный список поиском по нему, но это уже оптимизация интерфейса. Плюс время на каждую отправку запроса на сервер и возврат результат. Это можно решить комет-сервером конечно. На сколько быстро будут возвращены эти же 5-10-20 мегабайт? Но опять повторюсь, что все наименования оператор должен видеть, поэтому справочник из 10 000 наименований должен быть загружен в форму полностью.

Прояснил более менее ситуацию?

 

[Sufir]

справочник может содержать 10 000 наименований, оператор их все может и не помнить, как они точно называются и все наименования оператор должен видеть

И сможет пролистать список в 10 000 наименований в течение 30 секунд? Они у вас киборги что ли?

 

[baev]

поэтому справочник из 10 000 наименований должен быть загружен в форму полностью.

— блин, уже столько раз объяснили, что не должен.
Достаточно подгружать аяксом только то, что влазит на экран при перелистывании справочника вверх/вниз.

 

[SiZE]

И сможет пролистать список в 10 000 наименований в течение 30 секунд? Они у вас киборги что ли?

Если знать в каком направлении искать. Но это не моя задача найти что-то в справочнике. Моя задача сделать быстрым доступ к этому справочнику.

— блин, уже столько раз объяснили, что не должен.
Достаточно подгружать аяксом только то, что влазит на экран при перелистывании справочника вверх/вниз.

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