Хранение данных в респонсах

[Krjemilek]

Условие: Стоит задача по торговому аудиту. Описываем торговую точку примерно по 100-150 позициям. Поля генерятся в динамике - заранее неизвестны кол-во и названия. Имеется движок идеально реализующий нужное нам решение, но для каждой позиции создается респонс к документу торговой точки. По ТЗ возможна работа по ОЧЕНЬ плохим каналам связи. Точек примерно 1-2 тысячи.

Вопрос: большая ли будет разница по 1)времени и 2)траффику при репликации одного документа со 100 цифровыми полями с репликацией одного документа со 100 респонсами. Кто-нить сталкивался с такой траблой. Какие грабли возможно неожиданно лбом нащупать? Или разница не настолько ощутима что на нея можно не заморачиваться?

ЗЫ: Просьба, совет - провести эксперимент не давать. Собранный на коленках "стенд" дает рандомные не поддающиеся анализу данные, тем более что "катаем" документы по внутренней сетке.

Спасибо.

 

[Kizarek86]

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

 

[Omh]

Krjemilek
По мне, так нормально решение хранить данные в респонсах.
Главное, что бы их не модифицировать без дела, что бы не гонять туда-сюда просто так.

 

[Medevic]

А по-моему, лучше в одном документе хранить.
Если канал связи плохой, то очень вероятна ситуация, когда только часть респонсов реплицируется. В результате получим неполную или неверную информацию.

 

[lionk]

я тоже против респонов, и не только в плане трафика и репликаций, а в плане общесумарного количества документов в базе. если 10 точек и по каждой 100 респонов это ещё куда не шло, а что будет чрез два года експлуатации ситемы?
а ели надо обновлять масово какуюто информацию? (изменение общего атрибута) сохратить по разу 10 доков или 10х100. а если ночному агенту надо переберать все доки на предмет валидности?

оптимально это пару разных респонов(по класам хранения данных), лучше формы плодить.
та и прошли уже давно времена диалапа на 5kb/s.

 

[Constantin A Chervonenko]

Респонс, не респонс = связанный док-т (азве что "честный" респонс без родителя во вьюшке не покажется). Важно: ВСЁ в одном док-те или рассыпано по нескольким.
Один очень толстый док-т для плохих каналов вреден:
репликация транзакционна - в том смысле, что конкретный док-т либо реплицирован, либо нет, но - ЦЕЛИКОМ (докачки нет, и быть не может). При возобновлении оборванного сеанса док-т реплицируется заново.

С другой стороны множество очень мелких док-тов сильно удлиняют 1-ю фазу репликации...

Гм..

 

[K-Fire]

Ну если говорить об этом конкретном случае, т.е. при наличии 100-150 цифровых полей, то получим размер 1го документа не более 1-2 килобайт. Даже на ну очень плохих каналах связи это будет реплицироваться мгновенно