Скорость обработки данных
 

Вот есть тарифный калькулятор, который подсасывает данные из базы 1С, на 180'000 объектов. Делает, само собой, не особо шустро (паузы от 1 до 3 секунд).
Думаю переписать его на флеш со всякими красивостями и фичами, в связи с чем встает вопрос: рационально ли это? Не будет ли таких же задержек в обработке данных?

Насколько я знаю, напрямую с БД флеш работать не умеет, поэтому планируется разбить это огромную базу хотя бы частей на 100 и для каждой части сделать свой xml файл, который уже и парсить на предмет вводимых пользователем населенных пунктов.

Либо пойти какой-то другой дорогой? Буду благодарен любому совету.

Может, проще сделать небольшой PHP скрипт, который бы делал выборку необходимой части данных, преобразовывал в JSON и отдавал флешке?
Формат JSON предлагаю по тому, что в пыхе он нативно поддерживается, а в AS3 под него есть удобный пакет в составе as3corelib
По поводу задержек - можете тем же скриптом отдавать в неком своем формате , который можно будет парсить по частям (или тот же JSON, только загруженный как несколько дискретных кусков данных). И парсить, например, одну часть за один кадр. Таким образом, можно сделать отображение процесса чтения данных. Соответственно, задержка будет выглядеть как плавный процесс.

Хм. Ну как вариант.

Вообще дело в том, что базу 1С в хмл выгрузить, скажем, раз в сутки — не проблема. Так что можно и xml - обработать его флешем довольно просто.

Вопрос пока что в другом: будет ли XML/JSON файл на пару тысяч записей с параметрами достаточно быстро обрабатываться? Я понимаю, что можно сделать эту задержку красивой, чтоб пользователь не напрягался, но хотелось бы ее минимизировать по максимуму.

Вряд ли. Тем более, что на этой задаче программа, написанная не на AS3, подвисает на 3 секунды. Поэтому я и предложил грузить по кусочкам и парсить каждый кусочек отдельно для "размазывания" нагрузки по времени. В любом случае, что мешает попробовать и так и эдак? А уж как именно минимизировать нагрузку - тут решать только Вам =)

ты бы написал, что делает твой "тарифный калькулятор" в двух словах...
зачем ему все эти 180.000 записей ?

где и как он запускается..

gloomyBrain: спасибо! ) Будем пробовать :)

iillyyaa: калькулятор расчитывает стоимость доставки грузов в зависимости от нескольких параметров: вес, расстояние, габариты и скорость доставки.
180'000 записей - это населененные пункты, каждый из которых относится либо к определенной зоне, либо имеет коэффициент для расчета стоимости доставки.
Запускается на главной странице сайта сразу же при входе.

Ну вряд ли пользователю будет толк от показанных единовременно 180.000 записей. Вот штук 50 (ну 500) он воспринять сможет. Вот столько ему и отображайте, тут никаких проблем с производительностью не будет.
А если вы просто создадите 180.000 текстовых полей, каждый из которых будет лежать в своем контейнере, то ваш браузер не выдержит такой нагрузки.

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

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

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

сам фантазируй, но дели как то на части, что бы загрузить именно нужную часть

JSON - сильно грузить флеш при парсинге (при 180.000 записей парсер подохнет)
XML - легче для парсинга (вряд ли выдержит)
AMF - гораздо легче для парсинга на флеше (не проверял, но вдруг выдержит эти 180.000 записей?)
Отобразить тоже можно, 180.000 записей в экран все равно не влезут,
а отобразить 100 рендереров и переиспользовать их при скролллировании (меняя только данные) - вполне

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