обновление данных при multi-user работе

← →
Павел Калугин © (2012-01-09 16:09) [40]

> На форексах разных информации даже больше и ничего, нормально

От не зря я упоминал про специфический класс задач. Форексы и прочие биржи отдают котировки и т.п. ПО ЗАПРОСУ а не ПО ОБНОВЛЕНИЮ.

← →
Компромисс © (2012-01-09 16:10) [41]

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

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

← →
Petr V. Abramov © (2012-01-09 16:12) [42]

> На форексах разных информации даже больше и ничего, нормально.

бывает и такое, но в 25 раз реже, чем не бывает.
ТС же не хочет дать ответ на вопрос зачем ему это надо.

← →
Компромисс © (2012-01-09 16:13) [43]

Petr V. Abramov © (09.01.12 16:08) [39]

> - заказчик расписался, что сам несет ответсвенность за свои
> хотелки
> - готов платить за то, чтобы их потом переделывать

Конечно. У нас клиент загружает несколько сот тысяч строк и постоянно видит текущие изменения. Причем ему так понравилось, что он нас попросил и к другим скринам добавить автообновление. И я не нахожу это странным.

← →
Компромисс © (2012-01-09 16:15) [44]

Павел Калугин © (09.01.12 16:09) [40]

Форекс лишь демонстрирует, что нет ничего принципиально плохого в "мельтешении". RTMP демонстрирует, что сетка/сервер справится с 3 тысячами пользователей. Выше в ветке я писал, что один red5 сервер поддерживает до 20 тысяч подключений=пользователей.

← →
Petr V. Abramov © (2012-01-09 16:16) [45]

> Причем ему так понравилось, что он нас попросил и к другим
> скринам добавить автообновление.

ну чем бы дитя ни тешилось, лишь бы не руками

> И я не нахожу это стран

а вот это уже хуже
:)

← →
Компромисс © (2012-01-09 16:17) [46]

> ТС же не хочет дать ответ на вопрос зачем ему это надо.

Он уже дал ответ. Это надо не ему, а многим из тех 3 тысяч пользователей, кого бесит ежеминутное нажатие кнопки рефреш. Возможно, можно по таймеру нажиамть программно рефреш, но я не уверен, что нагрузка на сетку будет меньше. Тогда уже придется при рефреше отдавать порцию изменившихся данных, а на клиенте производить слияние.

← →
Petr V. Abramov © (2012-01-09 16:21) [47]

> . Это надо не ему, а многим из тех 3 тысяч пользователей,
> кого бесит ежеминутное нажатие кнопки рефреш. Возможно,
> можно по таймеру нажиамть программно рефреш, но я не уверен,
> что нагрузка на сетку будет меньше

а можно для начала попробовать убрать кнопку рефреш, может, никто и не заметит :)

← →
знайка (2012-01-09 16:24) [48]

У нас тоже есть места в системе где есть "автообновление", и мест не мало, тоже заказ, и ничего в этом странного мы не находим. И не форекс совсем.
Как его сделать - таймером, оповещением, все закачивать, или только изменения и т.д. и т.п., это уже другой вопрос.
Что прицепились непонятно...

← →
Павел Калугин © (2012-01-09 16:24) [49]

> Форекс лишь демонстрирует, что нет ничего принципиально
> плохого в "мельтешении". RTMP демонстрирует, что сетка/сервер
> справится с 3 тысячами пользователей. Выше в ветке я писал,
> что один red5 сервер поддерживает до 20 тысяч подключений=пользователей.
>

Ну и кому я писал, что биржи отдают данные ПО ЗАПРОСУ КЛИЕНТА?

← →
sniknik © (2012-01-09 16:28) [50]

> Я не путаю "неудобство" работы пользователя с отказом от безопасности.
ладно, еще пример, чисто на неудобство... правда к обновлению мало относится.
но вот прямо сейчас хотят поставить зависимость платежа (транзакции) от того напечатался чек на фискальнике или нет...
т.е. не напечатался, -> не делать платеж, вернуть деньги клиенту.
чтобы тебе не "рыть инет" сразу проблемы (то что тут явное удобство, это очевидно, нет неопределенности не нужно заниматься "претензионкой"),
- ошибка от печати фискального чека "не определена", нельзя сказать по ней на каком этапе произошла, до внесения суммы в фискальник, или после, т.е. ошибка типа "таймаут", устройство не отвечает, хотя все напечатало. и просто на обрезке чека "повисло" т.к. бумага кончилась.
- единственное определяющее (для ЦТО, можно даже спорить, если "в железе" суммы не будет) это глянуть на чек, фискальная строка присутствует? значит ок, нет? значит нет, даже если операция ок.
- по закону печать чека подтверждает операцию, а не наоборот... хотя, это мало кого волнует, кроме налоговой когда пытаются на взятку "стрясти", но тут в любом случае причину найдут/придумают.

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

← →
sniknik © (2012-01-09 16:30) [51]

> Что прицепились непонятно...
"а зачем" хотим знать, ясности хотим, можно ли, нужно ли, оправдано ли это делать.
а нам тут "это необходимо т.к. иногда, это вот сделано". но только это не доказательство.

← →
antonn © (2012-01-09 16:39) [52]

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

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

> ТС же не хочет дать ответ на вопрос зачем ему это надо.

а нам это не надо знать

← →
знайка (2012-01-09 16:39) [53]

Вот алигарх покупает Pagani Zonda дочери малолетней, спросите у него "а зачем?". :)

← →
Компромисс © (2012-01-09 16:41) [54]

Павел Калугин © (09.01.12 16:24) [49]

> Ну и кому я писал, что биржи отдают данные ПО ЗАПРОСУ КЛИЕНТА?

Естественно. Практически невозможно оповещать миллионы клиентов.

sniknik © (09.01.12 16:28) [50]

> сделаешь?

Нет, конечно. А вообще не вижу связи с предыдущей дискуссией. Если бы автообновление иногда/часто работало неправильно, я бы тоже его отказался делать. Ибо я отличаю неудобство не только от нарушения безопасности, но и от некорректности работы :)

← →
Компромисс © (2012-01-09 16:41) [55]

← →
sniknik © (2012-01-09 16:53) [56]

> Ибо я отличаю неудобство не только от нарушения безопасности, но и от некорректности работы :)
не везде... только где тебе хочется -
первый пример
sniknik © (09.01.12 15:57) [32]
и безопасно, и корректно. и удобно всем... кроме того кто "по ушам получит", за невнимательность, т.е. тот кто реально с программой работает (а вот фенечки разные, типа обсуждаемой, это обычная менеджерская задумка, при не незнании того как оно работает, т.е. "пятиминутное знакомство, и решение по верхам").
причем делали бы чат, почтового клиента, одной таблицы, только добавления ... да не вопрос. но тут про общего клиента, по работе с субд, и изменения вообще. разница однако.

← →
Компромисс © (2012-01-09 17:05) [57]

sniknik © (09.01.12 16:53) [56]

> не везде... только где тебе хочется -
> первый пример
> sniknik © (09.01.12 15:57) [32]

Посмотри внимательнее. Это было обращено не ко мне и я не ответил. Я в любом случае не ответил бы, потому что не понял суть проблемы. Лет 10 назад я участвовал в написании комплекса программ товарно-денежного учета, так у нас там при списании можно было редактировать все цены (и закупочные), которые применялись только для текущей операции. То есть цены по остаткам товары вообще не менялись.

← →
sniknik © (2012-01-09 18:09) [58]

> То есть цены по остаткам товары вообще не менялись.
именно, и это правильно, но тем не менее есть операции (переоценка) которая их меняет. и вот этом "проблема автообновления" здесь, нужно менять (раз клиент хочет, но по правилам/логике учетной системы меняться не должно, должно быть = как в накладной.
это просто еще один пример когда "не складывается".

← →
asail © (2012-01-09 18:47) [59]

> Павел Калугин © (09.01.12 16:24) [49]

> Ну и кому я писал, что биржи отдают данные ПО ЗАПРОСУ КЛИЕНТА?

И че? Разницу между клиентом и пользователем осознаем?

> sniknik © (09.01.12 16:28) [50]

Страшная вещь, эти ваши фискальники! Как вспомню - так вздрогну... :)

> sniknik © (09.01.12 16:30) [51]

> "а зачем" хотим знать, ясности хотим, можно ли, нужно ли,
> оправдано ли это делать

Логично. Однако, это не помешало сразу послать идеи ТС в топку, так и не получив вожделенной ясности.
Весь дальнейший спор получился о том, нужен ли сферическому коню хвост... :)

← →
DVM © (2012-01-09 18:55) [60]

Автоматическое обновление может быть использовано лишь там, где оно ReadOnly и не связано зависимостями с текущими действиями пользователя. Т.е на тех же биржах - есть графики и есть грубо говоря у чела кнопки покупаем продаем, то что он нажмет кнопку покупаем или продаем НЕ ГАРАНТИРУЕТ того что он купит или продаст имено по той цене что он только что увидел, так как есть более быстрые товарищи у которых более быстрые серверы и специально натасканные программы сами кликают на кнопки продаем покупаем в зависимости от условий и сидят они в соседнем доме от датацентра на котором биржевые сводки крутятся.

← →
sniknik © (2012-01-09 19:11) [61]

> Логично. Однако, это не помешало сразу послать идеи ТС в топку, так и не получив вожделенной ясности.
> Весь дальнейший спор получился о том, нужен ли сферическому коню хвост... :)
не путай причину и следствие. ответы такие были как раз потому, что вопрос о "сферическом коне". просто "возникла необходимость", без описания относительно чего, к чему применяется, зачем в конце концов. это признак коня в вакууме.

← →
asail © (2012-01-09 20:42) [62]

> DVM © (09.01.12 18:55) [60]

> Автоматическое обновление может быть использовано лишь там,
> где оно ReadOnly и не связано зависимостями с текущими
> действиями пользователя.

А вот и нет. В качестве примера могу привести сетевые аркадные игры, типа Counter Strike и подобных. Что мы тут имеем? Во-первых, обновление там более, чем автоматическое - игрок практически в реальном времени видит изменения, вызванные действиями других игроков. И во-вторых, своими действиями очень так даже может влиять на остальных игроков и на ситуацию в целом.

> sniknik © (09.01.12 19:11) [61]

Это больше относилось к
> Германн © (09.01.12 01:48) [4]

Наиболее логичным было бы всеж уточнить у ТС задачу, а уж потом поминать фантастику всуе... :)

← →
DVM © (2012-01-09 20:51) [63]

> asail © (09.01.12 20:42) [62]

вот и будет вместо бухгалтерии Counter Strike сплошной.

← →
antonn © (2012-01-09 21:14) [64]

> вот и будет вместо бухгалтерии Counter Strike сплошной.

какой бухгалтерии?

← →
sniknik © (2012-01-09 21:20) [65]

> а уж потом поминать фантастику всуе... :)
не смотрел фильмы, когда типа просматривает кто то документ на компе и ... аааа, ооо, быстрее, быстрее, его удаляют... с другой машины, из сети, но пропадает он кусками с локального компа. %)

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

← →
sniknik © (2012-01-09 21:22) [66]

> какой бухгалтерии?
база, mssql, клиент сервер, 2-3тыс клиентов... игра? 2+2?

но вообще, хреновой бухгалтерии, раз дошли до подобных вопросов.

← →
antonn © (2012-01-09 21:27) [67]

> база, mssql, клиент сервер, 2-3тыс клиентов... игра? 2+2?

call-центр
фантазии не хватает на что либо другое кроме "бухгалтерии"? :)

← →
asail © (2012-01-09 21:39) [68]

> sniknik © (09.01.12 21:22) [66]
> > какой бухгалтерии?
> база, mssql, клиент сервер, 2-3тыс клиентов...

Нифигасе такая бухгалтерия! 2-3тыс клиентов... :))

> antonn © (09.01.12 21:27) [67]

> call-центр
> фантазии не хватает на что либо другое кроме "бухгалтерии"?
> :)

фантазии хватает, а call центров с таким количеством операторов я лично не видел, хотя был во многих.

> DVM © (09.01.12 21:39) [69]

> фантазии хватает, а call центров с таким количеством операторов
> я лично не видел

А бухгалтерию видел?

> sniknik © (09.01.12 21:22) [66]

> но вообще, хреновой бухгалтерии, раз дошли до подобных вопросов

> DVM © (09.01.12 21:40) [70]

> ГОСПЛАН

Сошлось. Ну вот и выяснили, чем ТС занимается...

> DVM © (09.01.12 21:39) [69]
>
>
> > antonn © (09.01.12 21:27) [67]
>
>
> > call-центр
> > фантазии не хватает на что либо другое кроме "бухгалтерии"?
>
> > :)
>
> фантазии хватает, а call центров с таким количеством операторов
> я лично не видел, хотя был во многих.

но это ведь не значит что их нет? :)

> asail © (09.01.12 21:41) [72]

> Вот видишь, как нам тут автообновления не хватает? :)

теперь ясно почему плановая экономика в СССР не пошла - автообновления не было, не успевали все запланировать как надо, отсюда дефицит и прочие беды.

> DVM © (09.01.12 21:44) [75]

Заметь, у них еще не только Counter Stik"a, но даже, обычной косынки небыло... А то, вообще бы - адъ! :)

зато чай уже был изобретен :)

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

+
в лучшие годы правда, счаз правда много меньше ;(
(развалились в связи с кризисом на 4 самостоятельных конторы).

← →
знайка (2012-01-09 22:14) [80]

> 356
и все бухгалтеры?

обновление данных при multi-user работе Найти похожие ветки