Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Прочее";
Текущий архив: 2012.05.20;
Скачать: [xml.tar.bz2];

Вниз

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

 
Компромисс ©   (2012-01-10 12:34) [120]

vuk ©   (10.01.12 12:24) [119]

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


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


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



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


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


 
Ega23 ©   (2012-01-10 12:38) [121]

Ух-ты, какой тут прячь опять идёт!!!
И лица одни и те же...

1. Автообновление - ничего хорошего, равно как и ничего плохого в этом нет.
2. Автообновление плохо реализуется с привычными DAC-ами, по-хорошему надо протокол свой писать + трёхзвенку. Если такая архитектура выбрана изначально - нет проблем. Если нет - считай, что с нуля писать надо. Не каждый заказчик будет готов оплатить такую работу.
3. Я бы не хотел пользоваться программой в том виде, как она описана в [0]. Это будет Адъ и Израиль.


 
sniknik ©   (2012-01-10 12:51) [122]

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

p.s. почти реальное "тз".


 
Компромисс ©   (2012-01-10 12:54) [123]

sniknik ©   (10.01.12 12:51) [122]

Это к чему? Может, по автообновлению еще и шины на зимние поменять? :)


 
sniknik ©   (2012-01-10 12:58) [124]

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

ну так как насчет вариантов?


 
sniknik ©   (2012-01-10 12:59) [125]

и кстати "клиент всегда прав" ваши слова.


 
vuk ©   (2012-01-10 13:02) [126]

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

> У нас клиенты загружают до 400 тысяч строк с режимом автообновления.

Ужос. И что, есть хоть один человек, который в реальности все эти 400 тыс. просматривает с разумной целью? У нас, пожалуй, несколько сотен записей в выборке - уже повод придумывать средства фильтрации на серверной стороне.


> Это не наш случай, у нас строка исчезает сразу.

Представляю себя на месте пользователя. Сижу втыкаю на экран... И тут фигак - обновление свалилось, смотрю почему-то уже в какое-то другое место. И как теперь искать то, на что смотрел до обновления? И это еще хорошо, если момент обновления удалось увидеть. А если я от экрана отвернулся, по делам отлучился и т.д., то что будет?


 
знайка   (2012-01-10 13:09) [127]


> Представляю себя на месте пользователя. Сижу втыкаю на экран..
https://www.bwin.com/ru/livebets.aspx
И пользователей миллионы. автообновление по полной, все пропадает, появляется, мигает и звуки издает. Никаких проблем ни у пользователей ни у разработчиков.


 
Компромисс ©   (2012-01-10 13:12) [128]

sniknik ©   (10.01.12 12:58) [124]

Твое ТЗ не имеет никакого отношения к [0], в котором всё ясно.

sniknik ©   (10.01.12 12:59) [125]

Лучше другой вариант - "Любой каприз за Вашт деньги" :)

vuk ©   (10.01.12 13:02) [126]

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


> И тут фигак - обновление свалилось, смотрю почему-то уже
> в какое-то другое место

Есть специфика - добавлений гораздо меньше, чем редактирований. Фильтруют обычно по естественному ключу, который не редактируется. Плюс структура не плоская, а иерархическая (4-5 уровней вложенности). Поэтому пользователю достаточно удобно - они обычно не больше 100 записей раскрывают, потом сворачивают нод и открывают другой, чтобы посмотреть другие 100 записей. А в это время в свернутых нодах невидимо для пользователя работает автообновление...


 
Ega23 ©   (2012-01-10 13:13) [129]


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


Это read-only данные.


 
vuk ©   (2012-01-10 13:15) [130]

to знайка   (10.01.12 13:09) [127]:

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

Этол не система обработки данных. Скорее система оповещения, типа информационного табло. В похожих случаях (но в сильно другой области) у нас автообновление тоже есть.


 
Ega23 ©   (2012-01-10 13:15) [131]


> Есть специфика - добавлений гораздо меньше


Вот именно. Есть специфика. Универсальный вариант - по запросу. Автообновление - не универсальный вариант.


 
asail ©   (2012-01-10 13:23) [132]

Я вот просто хочу уточнить у противников автообновления следующие вопросы:
1. Считаете ли вы, что разработка системы с автообновлением в принципе невозможна по техническим причинам?
2. Считаете ли вы, что не существует такого типа задач, где автообновление было бы удобно для пользователя?
Вот просто - Да или Нет...


 
Ega23 ©   (2012-01-10 13:27) [133]

1. Вполне возможна.
2. Существуют.
3. Тут нет противников. Тут есть масса народа, которая через стадию "Вася данные изменил, а у меня сразу всё обновилось" уже проходили и не раз. И в большинстве случаев как раз для автообновления должны быть довольно веские причины, а не наоборот.


 
знайка   (2012-01-10 13:28) [134]


> Этол не система обработки данных.
Так вы сами про ридонли ситуацию привели.
И еще, там ставки делаешь, и оно редактируется, и обновляется автоматически, т.е. если ставку заблокировали на сервере, то и в купоне она либо заблокируется либо исчезнет, смотря как реализованно.


 
Компромисс ©   (2012-01-10 13:29) [135]


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


Правильно, и я эти довольно веские причины уже описывал выше:
1) Заказчик это хочет
2) Это технически возможно.


 
asail ©   (2012-01-10 13:29) [136]


> Павел Калугин ©   (10.01.12 10:27) [95]

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

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


 
Ega23 ©   (2012-01-10 13:32) [137]


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


И все пользователи сразу увидят блокировку, а не только ты.
Не смешно.


 
asail ©   (2012-01-10 13:34) [138]


> Ega23 ©   (10.01.12 13:27) [133]

Полностью согласен. Об чем и речь...

> И в большинстве случаев как раз для автообновления должны
> быть довольно веские причины, а не наоборот

И кто-то тут говорил обратное? Я, видимо, пропустил... :)


 
знайка   (2012-01-10 13:35) [139]


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


 
Ega23 ©   (2012-01-10 13:35) [140]


>
> Правильно, и я эти довольно веские причины уже описывал
> выше:
> 1) Заказчик это хочет
> 2) Это технически возможно.


И тебе уже неоднократно отвечали, как и с редактированием в гриде:
1) Заказчик готов это оплатить
2) Заказчик готов оплатить потом переделку этого "взад", если он осознает, что хотел "странного".
При выполнении этих пунктов - пуркуа бы и не па?
"Желание клиента - закон" выполняется только в одном случае: это действительно клиент, а не "потенциальный клиент".


 
Компромисс ©   (2012-01-10 13:38) [141]

Ega23 ©   (10.01.12 13:35) [140]

Естественно. Тогда об чем спор вообще? :)


 
Ega23 ©   (2012-01-10 13:40) [142]


> Естественно. Тогда об чем спор вообще? :)


Да нету никакого спора.
Но, согласись, в случае [0] с вероятностью 99% - это тупо незнание технологий, архитектур и вообще дилетантство.


 
Компромисс ©   (2012-01-10 13:46) [143]


> Но, согласись, в случае [0] с вероятностью 99% - это тупо
> незнание технологий, архитектур и вообще дилетантство.


Не соглашусь. С вероятностью 1%. Наверное, об этом и спор :) У разных людей разный опыт. Если на экране есть кнопка "Refresh", то должен быть и checkbox "AutoRefresh"


 
Компромисс ©   (2012-01-10 13:48) [144]

+ еще комбобокс "Каждые N секунд"


 
asail ©   (2012-01-10 13:54) [145]


> Ega23 ©   (10.01.12 13:40) [142]

> Да нету никакого спора.

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


 
vuk ©   (2012-01-10 13:56) [146]

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

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

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


> Фильтрация на клиенте очень быстрая, даже быстрее, чем на
> сервере,  

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


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

У нас тоже. Но работает это все, сюрпрайз, на уровне сервера. А клиентский код о системе контроля доступа к данным, как правило, вообще не догадывается. Правда, каким боком эт к автообновлениям - мне вообще не понятно. :)


 
Ega23 ©   (2012-01-10 14:00) [147]


>  то должен быть и checkbox "AutoRefresh"
> + еще комбобокс "Каждые N секунд"


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


 
vuk ©   (2012-01-10 14:03) [148]

to знайка   (10.01.12 13:28) [134]:


> Так вы сами про ридонли
> ситуацию привели.

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


 
vuk ©   (2012-01-10 14:05) [149]

to Компромисс ©   (10.01.12 13:46) [143]

> Если на экране есть кнопка
> "Refresh", то должен быть и checkbox "AutoRefresh"

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


 
Павел Калугин ©   (2012-01-10 14:07) [150]


> asail ©   (10.01.12 13:29) [136]
>
> > Павел Калугин ©   (10.01.12 10:27) [95]
>
> > > Разницу между клиентом и пользователем осознаем?
> >
> > И в чем разница? Данные у пользователя обновляются не
> по
> > инициативе сервера. Как это реализовано - он сам капу
> давит
> > или таймер шуршит дело десятое.
>
> Вот это ты пользователю объясни... Еще раз, пользователю
> по-барабану, сервер ли рассылает сообщения об изменениях
> или клиент стучится до сервера по таймеру. Да хоть, сисадмин
> будет каждые две минуты с флешкой прибегать и обновлять
> данные... Все это - различные способы технической реализации
> одной и той же функциональности, и с точки зрения пользователя,
>  значения не имеют.

Сээр, ну вы просто пользователь? Ну тогда Вам все равно. Иначе сами должны понимать разницу между

> если пользователь 1 изменил какую-то информацию, у других
> пользователей эти изменения отобразились автоматом

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


 
Компромисс ©   (2012-01-10 14:07) [151]


> 400 тыс записей не вываливаются из реальных выборок нигде.
>  Они не нужны.


Мне тоже. Клиент хочет :)


> Что-то слабо себе представляю ситуацию, в которой система
> фильтрации на клиенте будет работать быстрее, чем на сервере.
>  Особенно, если критерий подразумевает некие вычисления
> по связанным данным.


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


> Но работает это все, сюрпрайз, на уровне сервера.


Обижаешь :) У нас всё тоже очень серьезно в плане безопасности. Детали не скажу, конечно :)


 
Омлет ©   (2012-01-10 14:12) [152]

Во раздули-то..
Кстати, основная фишка аппаратов Блэкберри в том, что там письма приходят мгновенно, а не пока аппарат проверит почту по таймеру. Двусторонняя связь - удобная штука.


 
Павел Калугин ©   (2012-01-10 14:13) [153]


> asail ©   (10.01.12 13:54) [145]
>
> > Ega23 ©   (10.01.12 13:40) [142]
>
> > Да нету никакого спора.
>
> Спор есть, т.к. некоторые товарищи сразу отнесли саму возможность
> автообновления в разряд фантастики.

Не совсем. Дословно - неоправданные требования автообновления отнесены в область бреда заказчика. Со всеми вытекающими. Как выше Олег писал, если заказчик регулярно оплачивает реализацию своего очередного бреда и адекватно переносит сроки сдачи - почему бы и нет. Но итоговым счетом и сроками заказчик все равно будет не доволен


 
sniknik ©   (2012-01-10 14:17) [154]

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

вот и выходит единственное кому это нужно (в этом варианте) это бездельничающему начальнику.

> основная фишка аппаратов Блэкберри в том, что там письма приходят мгновенно
всем, или все-таки адресно?


 
Компромисс ©   (2012-01-10 14:20) [155]

sniknik ©   (10.01.12 14:17) [154]

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


 
Ega23 ©   (2012-01-10 14:30) [156]


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


Ну не только. В моём очень конкретном случае - дежурному прапорщику на пульте контроля. Всякие сообщения от датчиков смотреть. Где-то тревога (по различным причинам), где-то warning, мол, в самотестирование ушло, где-то просто информационные сообщения.
Но, опять же, это исключительно read-only режим. И не более N записей на оперативном экране. Надо больше - будьте любезны в архив, с фильтрами, условиями выборки и т.п.

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


 
sniknik ©   (2012-01-10 14:31) [157]

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


 
Ega23 ©   (2012-01-10 14:33) [158]


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


почему бы и нет? Вот у меня в notepad++ был открыт некий файл. Который я потом взял и удалил с диска. Почему он должен у меня закрыться в notepad?


 
sniknik ©   (2012-01-10 14:35) [159]

> Всякие сообщения от датчиков смотреть.
о блин, а у нас тоже есть подобное, система ошибок для дежурного администратора... но вот как то я ее не воспринимаю как программу по работе с субд... единственное чтение, и показ больше ничего не делает.
да еще с автообновлением, это единственное что она делает, т.е. не авто, но просто процесс.


 
Компромисс ©   (2012-01-10 14:38) [160]


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


Ок, в таком случае обновление не нужно. Возможно, временно не нужно.



Страницы: 1 2 3 4 5 вся ветка

Форум: "Прочее";
Текущий архив: 2012.05.20;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.84 MB
Время: 0.021 c
15-1326277214
OW
2012-01-11 14:20
2012.05.20
по Oracle и PL/SQL Developer. Как его научить автоформатировать?


2-1326964751
CRLF
2012-01-19 13:19
2012.05.20
Визуальное редактирование графов


15-1326702784
картман
2012-01-16 12:33
2012.05.20
массив случайных чисел заданной суммы


15-1326400202
Юрий
2012-01-13 00:30
2012.05.20
С днем рождения ! 13 января 2012 пятница


15-1326395711
Jeer
2012-01-12 23:15
2012.05.20
Опять про Фобос..





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский