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

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

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

← →
sniknik © (2012-01-09 22:35) [81]

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

← →
Anatoly Podgoretsky © (2012-01-09 23:26) [82]

> antonn (09.01.2012 15:45:29) [29]

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

← →
antonn © (2012-01-10 00:01) [83]

> И после обновления, ему приходится искать

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

← →
Знаток (2012-01-10 00:26) [84]

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

← →
Германн © (2012-01-10 00:32) [85]

> Знаток (10.01.12 00:26) [84]

Знаток - Niel?
Или на винграде подсмотрел?
:)

← →
vuk © (2012-01-10 00:34) [86]

to Anatoly Podgoretsky © (09.01.12 23:26) [82]:

> ему приходится искать, а где та запись, которую я только
> что читал.

Это да. Если просто надо запомнить на какой записи стояли и после обновления встать туда же, то это мелочь. А вот особенно будет весело, если запись перестанет условию фильтра какого-нибудь удовлетворять. :)

← →
sniknik © (2012-01-10 01:02) [87]

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

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

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

← →
sniknik © (2012-01-10 01:10) [88]

> Наверное те кто реализовывал интерфейс об этом позаботились :)
у них нет изменений по отфильтрованному на клиенте полю. это + к тому что выше.
изменений ИЗВНЕ, причем для локального рекордсета возможно единственному ключевому... ну вот было это 1 записью, с ключём = 1, а стало, усилиями редактора в сети, 1315-и... и найти не по чему... (ключ изменился. помним?)

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

← →
antonn © (2012-01-10 01:24) [89]

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

а это все делает человек в сабжевом сообщении? Он так и сказал что все это делает?
кстати, в MS Outlook есть сортировка, группировка.. что, однако, не мешает

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

и ничего, делали, и клиенты не уходили.

← →
sniknik © (2012-01-10 08:10) [90]

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

> однако, не мешает
ты реально не понимаешь? или чисто ради "поспорить"? если второе то честно скажи чтобы я перестал пытаться тебе объяснять.

она во первых мешает... если там сделать правило и раскладывать письма по группам то для них перестает работать уведомление о новых в трей... если конечно не пришло новое письмо во "входящие" вне правил.

во вторых данные там статичные (пассивные) любой фильтр/сортировка будут неизменны, а в практически любом базовом клиенте, данных во первых больше чем 1 или 2 таблицы во вторых они активны, могут меняться. не добавляться таких же статичных как в чате, а именно меняться.

← →
MonoLife © (2012-01-10 08:11) [91]

бурное обсуждение..., а ТС и след простыл...

> Программой пользуются 2-3 тыс. людей, большинство из них
> бесит такой подход,

это значит более 50% юзеров, неужели ~1,5 тыс. человек пожаловались, что нет автообновления?!

> Павел Калугин © (09.01.12 15:54) [31]
> Anatoly Podgoretsky © (09.01.12 23:26) [82]

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

← →
OW © (2012-01-10 08:44) [92]

call-центр, ~ 1000 клиентов
автообновление или его аналог был в ТЗ, послали с автообновлением нафиг. Начальник грамотный у меня, придумал слова нужные :)

+постарались сделать, что бы один оператор не зависел от любого другого.

Зависимость осталась, но сделал (сам делал этот момент) так, что при перезаписи уже измененного поля выходит окно, где написано что запись с момента взятия в работу была изменена. И три варианта записи показаны,
исходный, который юзер взял в работу
который сейчас в БД,
который сейчас у юзера.
(Сделал по аналогии с демкой к ODAC на св-во CashedUpdates у DataSet)
И предлагается выбрать окончательный вариант к записи в БД.
А если что-то успеет изменится, предлагается еще раз это окно. Зациклено до полного исключения конфликта.
Залогированы такие моменты. Судя по логам, никто не видел окно более 2х раз подряд. А два раза видели только при массовых операциях, когда выделяли более 100 записей и говорили обновить какое-то поле. (перевести в др.категорию, например, и передать в другую службу и т.п.)

← →
sniknik © (2012-01-10 09:46) [93]

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

ИМХО, т.к. только с таким при подобных "заказах" и встречался.
+ такие, даже поняв, что что-то не нужно, не отменяют решений... максимум чего от них было "а сделайте настройкой, чтобы и так и так можно было".

p.s. жаль только что "весу" при решениях у этого одного гораздо больше чем 50%.

← →
MonoLife © (2012-01-10 09:52) [94]

> sniknik © (10.01.12 09:46) [93]

да, реально так оно и бывает..

← →
Павел Калугин © (2012-01-10 10:27) [95]

> asail © (09.01.12 18:47) [59]
>
> > Павел Калугин © (09.01.12 16:24) [49]
>
> > Ну и кому я писал, что биржи отдают данные ПО ЗАПРОСУ
> КЛИЕНТА?
>
> И че? Разницу между клиентом и пользователем осознаем?

И в чем разница? Данные у пользователя обновляются не по инициативе сервера. Как это реализовано - он сам капу давит или таймер шуршит дело десятое.

← →
Павел Калугин © (2012-01-10 10:30) [96]

> asail © (09.01.12 20:42) [62]
>
> > DVM © (09.01.12 18:55) [60]
>
> > Автоматическое обновление может быть использовано лишь
> там,
> > где оно ReadOnly и не связано зависимостями с текущими
>
> > действиями пользователя.
>
> А вот и нет. В качестве примера могу привести сетевые аркадные
> игры, типа Counter Strike и подобных. Что мы тут имеем?
> Во-первых, обновление там более, чем автоматическое - игрок
> практически в реальном времени видит изменения, вызванные
> действиями других игроков. И во-вторых, своими действиями
> очень так даже может влиять на остальных игроков и на ситуацию
> в целом.

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

← →
Павел Калугин © (2012-01-10 10:37) [97]

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

Неболшая, по сути, булгахтерия. Кстати практически любую учетную систему можно бухгалтерией назвать. И колцентр, в принципе, тоже. Ибо там необходим учет :)

← →
Компромисс © (2012-01-10 10:39) [98]

sniknik © (09.01.12 18:09) [58]

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

Не понял. У нас происходила заморозка (резервирование) товара при любых операциях, то есть при выборе товара на переоценку/накладную требовалось указать количество, которое сразу же (до нажатия кнопки "Провести транзакцию") становилось недоступным/невидимым для других операций. Поэтому невозможен был конфликт между переоценкой и продажей. В тех редких случаях, когда несколько пользователей указывало один и тот же товар (так что в сумме товара не хватило бы), один из пользователей обламывался с получением сообщения "Недостаточно товара G. Имеется только N" и мог повторить попытку после уменьшения желаемого количества. Даже здесь автообновление очень помогло бы :)

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

> один из пользователей обламывался

Причем обламывался сразу же, при заморозке товара, а не при нажатии "Провести транзакцию".

← →
Компромисс © (2012-01-10 10:44) [100]

DVM © (09.01.12 18:55) [60]

Автоматическое обновление может быть использовано лишь там, где:
1) этого хочет клиент
2) это технически возможно

← →
Компромисс © (2012-01-10 10:50) [101]

vuk © (10.01.12 00:34) [86]

> А вот особенно будет весело, если запись перестанет условию
> фильтра какого-нибудь удовлетворять. :)

У нас такое бывает. Но:
1) если запись была в процессе редактирования, то она не могла поменяться, потому как при входе в режим редактирования она локируется (не в БД, а через RTMP) и никакой другой клиент не может ее редактировать
2) иначе позиция курсора не меняется
В результате, 1 и 2 приводят к тому, что позиция курсора никогда не меняется :)

← →
Компромисс © (2012-01-10 10:53) [102]

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

У нас разное понимание отображения нового. Не должен экран "прыгать", подсвечивая красным измененные строки, а фиолетовым измененные значения. Экран остается таам же, где он был. Если в текущем экране есть измененные строки, они актуализируется. Без всяких подсвечиваний (если не требуется по ТЗ, конечно). Если очень надо узнать именно изменения, то можно где-то добавить статус "Изменилось N строк" с кнопкой "Просмотреть изменения"

← →
Компромисс © (2012-01-10 10:55) [103]

> (ключ изменился. помним?)

Вот люди. Вместо того, чтобы нормально БД проектировать, пытаются отказаться от автообновления. Типа фильтр - это плохо, потомоу что очень медленно искать данные в текстовом файле размером 2 Tb. Не должен ключ меняться никогда. Если естественный ключ меняется, значит, надо было делать суррогатный.

← →
Компромисс © (2012-01-10 10:58) [104]

> Зависимость осталась, но сделал (сам делал этот момент)
> так, что при перезаписи уже измененного поля выходит окно,
> где написано что запись с момента взятия в работу была
> изменена

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

← →
sniknik © (2012-01-10 10:59) [105]

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

← →
Компромисс © (2012-01-10 11:05) [106]

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

Пока не донес :) Не понимаю до сих пор. Почему "по логике автообновлиния низя, никаких резервирований, никаких транзакций с захваченным "куском" данных, никаких блокировок"? По логике нельзя позволять двум пользователям редактировать одни и те же данные, независимо от наличия автообновления. Поэтому локировка обязана быть. Как показывает мой (и не только) опыт, автообновления не препятствует этому, даже наоборот, помогает с локировкой. Можно конкретнее? Приведи, пожалуйста, пример, когда без автообновления работает, а с ним - проблемы?

← →
Компромисс © (2012-01-10 11:07) [107]

> Приведи, пожалуйста, пример, когда без автообновления работает,
> а с ним - проблемы?

Кстати, с точик зрения формальной логики, этого будет недостаточно, чтобы доказать, что автообновление всегда плохо. А вот мне достаточно привести пример, когда автообновление реально помогает (не с read only данными), и я его уже приводил, а он опровергнут не был.

← →
vuk © (2012-01-10 11:08) [108]

to Компромисс © (10.01.12 10:53) [102]:

> У нас такое бывает. Но:1) если запись была в процессе редактирования,
> то она не могла поменяться, потому как при входе в режим
> редактирования она локируется (не в БД, а через RTMP) и
> никакой другой клиент не может ее редактировать2) иначе
> позиция курсора не меняетсяВ результате, 1 и 2 приводят
> к тому, что позиция курсора никогда не меняется :)

А вот ситуация:
1. Некто Петя получил список каких-то операций в определенном состоянии и сидит их спокойно изучает безо всякого редактирования.
2. Некто Вася изменяет состояние операции, которую в данный момент просматривает Петя.

Вопрос. Что должно произойти у Пети, если работает система автообновлений?

vuk © (10.01.12 11:08) [108]

> А вот ситуация:
> 1. Некто Петя получил список каких-то операций в определенном
> состоянии и сидит их спокойно изучает безо всякого редактирования.
>
> 2. Некто Вася изменяет состояние операции, которую в данный
> момент просматривает Петя.
>
> Вопрос. Что должно произойти у Пети, если работает система
> автообновлений?

Если Петя выполнил операцию получения отчета, то ничего, потому как он сидит в каком-нибудь Excel или PDF reader. Если Петя изучает список в том же режиме, что используется для обычной работы (редактирования), то он увидит новое состояние. У нас так сделано, во всяком случае, и никто не жалуется. Если очень хочется, можно вынести настройку автообновления (чекбокс) в интерфейс и пусть пользователь сам решает, что ему надо.

← →
знайка (2012-01-10 11:21) [110]

> А вот ситуация:
И что такого в этой ситуации? ситуация как ситуация, ну актуализировались данные, ну и что, волосы, как говорили тут, рвать сразу надо?
У нас в такой ситуации не Вася, а несколько десятков сервисов в режиме 24/7, и все волосатые до сих пор.

← →
знайка (2012-01-10 11:24) [111]

Читаешь и складывается ощущение, мол кто уже столкнулся с необходимостью, то криминала не видит, остальные в панике. :)

to Компромисс © (10.01.12 11:21) [109]:

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

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

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

> Повторяю еще раз.
не старайся, не поймут, им это не выгодно...

vuk © (10.01.12 11:27) [112]
Повторяю еще раз. Состояние - критерий выборки у Пети. Состояние изменилось. После обновления увидит ли Петя запись, которую изучал до изменения состояния?

Странный вопрос. Автообновление не реализовано автоматически каким-то стандартным компонентом, поэтому поведение зависит от того, как мы его реализуем. А реализовать мы можем по-разному, в зависимости от ТЗ. Можно запретить удаление из отображаемого набора текущей строки (кстати, а зачем, ведь строки уже нет), можно показывать старое ее значение при редактировании другим пользователем (кстати, а зачем, ведь зстарые начения уже не вернешь, хотя...), можно показывать новое значение (самое правильное).
В том же Flex типичная реализация проста до безобразия - меняется элемент коллекции (после поиска по ключу) и всё... Даже рефреш вызывать не надо :)

sniknik © (10.01.12 11:29) [114]

> > Повторяю еще раз.
> не старайся, не поймут, им это не выгодно...

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

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

У нас работа клиента вообще не завязана на БД и тем более какие-то там таблицы. И это правильно ИМХО. Вон мы недавно на nosql перенесли кое-что, клиентов даже менять не пришлось :) Data Transfer Object - наше всё :)

Компромисс © (10.01.12 11:40) [115]:

> Можно запретить удаление из отображаемого набора текущей
> строки

В таком случае, когда наступит момент, подходящий для того, чтобы строка таки пропала из выборки, как несоответствующая критерию?

> (кстати, а зачем, ведь строки уже нет)

Строка есть, но в другом состоянии. Это повод отобрать у Пети возможность изучать операцию?

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

Дело не в том, какое состояние строки видит пользователь, а в том, видит ли он строку вообще.

> можно показывать новое значение (самое правильное).

Новое значение чего? Состояние строки не соответствует критерию выборки.

> В том же Flex типичная реализация проста до безобразия -
> меняется элемент коллекции (после поиска по ключу) и всё.
> .. Даже рефреш вызывать не надо :)

Не надо путать рабочий процесс пользователя с внутренними механизмами библиотек.

vuk © (10.01.12 11:59) [117]

На все вопросы - один ответ: в зависимости от ТЗ. У нас, например, редактируемая запись отображается всегда, даже если в процессе редактирования она перестает удовлетворять фильтру.
На казуистику тратить время неохота, уж извините.

to Компромисс © (10.01.12 12:07) [118]:

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

Я специально сказал, что запись не редактируется. :)

> На казуистику тратить время неохота, уж извините.

Это не казуистика, это вопросы, которые возникают сразу, как только кто-то говорит "а давайте прикрутим автообновление!". По крайней мере у меня возникают. Фигня в том, что однозначного ответа на них нет. Потому, что там, где нужно активное взаимодействие с пользователем в системах обработки данных, мы либо ломаем кому-то рабочий процесс либо сводим смысл автообновлений к нулю.

vuk © (10.01.12 12:24) [119]

Раз, не казуистика, можно и продолжить :)
У нас клиенты загружают до 400 тысяч строк с режимом автообновления. Знаем, что плохо, но пока переубедить не получается. Даже с такими размерами проблем не возникает - Петя смотрит на экран, Васи меняют данные, Петя продолжает смотреть на экран. Стандартные компоненты "умные", чтобы не рисовать то,Ю что находится за пределами экаран, торможений нет. Если возникают вопросы, на которые "однозначного ответа нет", мы предлагаем возможные варианты заказчику и он делает свой выбор. Всегда видит актуальное состояние, никогда не происходит перезаписи изменений и прочих типичных многопользовательских проблем.

> В таком случае, когда наступит момент, подходящий для того,
> чтобы строка таки пропала из выборки, как несоответствующая
> критерию?

Это не наш случай, у нас строка исчезает сразу. Всегда показывается актуальное состояние. Текущая строка может исчезнуть, если она удалена или не удовлетворяет больше фильтру. Это уже будет ответом на
> Новое значение чего? Состояние строки не соответствует критерию
> выборки.

> Не надо путать рабочий процесс пользователя с внутренними
> механизмами библиотек.

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

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