1. Требуются разработчики и тестеры для проекта codebyOS. Требования для участия в проекте: Знание принципов работы ОС на базе Linux; Знание Bash; Крайне желательное знание CPP, Python, Lua; Навыки системного администрирования. Подробнее ...

    Скрыть объявление

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

Тема в разделе "Lotus - Программирование", создана пользователем Krjemilek, 30 мар 2009.

  1. Krjemilek

    Krjemilek Гость

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

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

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

    Спасибо.
     
  2. Kizarek86

    Kizarek86 Well-Known Member
    Lotus team

    Репутация:
    0
    Регистрация:
    20 июл 2007
    Сообщения:
    860
    Симпатии:
    6
    а многозначные поля не подходят? с ними будет быстрее всего.
    Конечно будет медленне с респонсами, но вот насколько критично сказать затрудняюсь)
     
  3. Omh

    Omh Well-Known Member
    Lotus team

    Репутация:
    0
    Регистрация:
    4 июл 2007
    Сообщения:
    2.210
    Симпатии:
    0
    Krjemilek
    По мне, так нормально решение хранить данные в респонсах.
    Главное, что бы их не модифицировать без дела, что бы не гонять туда-сюда просто так.
     
  4. Medevic

    Medevic Что это ? :)
    Lotus team

    Репутация:
    0
    Регистрация:
    10 дек 2004
    Сообщения:
    3.346
    Симпатии:
    2
    А по-моему, лучше в одном документе хранить.
    Если канал связи плохой, то очень вероятна ситуация, когда только часть респонсов реплицируется. В результате получим неполную или неверную информацию.
     
  5. lionk

    lionk Well-Known Member

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

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

    Constantin A Chervonenko Well-Known Member
    Lotus team

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

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

    Гм..
     
  7. K-Fire

    K-Fire Гость

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

Поделиться этой страницей