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

← →
Dmitry1987 (2012-01-09 01:04) [0]

Каким образом можно решить проблему обновления данных в программах-клиентах при многопользовательской работе с субд (MS SQL Server). Сейчас программа работает так: например, пользователь 1 добавил новую запись. Чтобы в остальных программах-клиентах отобразились изменения другим пользователям нужно нажать на кнопку обновить. Программой пользуются 2-3 тыс. людей, большинство из них бесит такой подход, они хотят, чтобы, например, если пользователь 1 изменил какую-то информацию, у других пользователей эти изменения отобразились автоматом без лишних телодвижений с их стороны.

← →
DVM © (2012-01-09 01:07) [1]

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

и как это по их мнению должно выглядеть? ты поинтересуйся у тех кого это бесит.

← →
sniknik © (2012-01-09 01:41) [2]

работа она вообще бесит...

← →
Германн © (2012-01-09 01:47) [3]

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

Они захочут и рыбку съесть и ... :)

← →
Германн © (2012-01-09 01:48) [4]

> Dmitry1987 (09.01.12 01:04)
>
> Каким образом можно решить проблему обновления данных в
> программах-клиентах при многопользовательской работе с субд
> (MS SQL Server). Сейчас программа работает так: например,
> пользователь 1 добавил новую запись. Чтобы в остальных
> программах-клиентах отобразились изменения другим пользователям
> нужно нажать на кнопку обновить. Программой пользуются 2-
> 3 тыс. людей, большинство из них бесит такой подход, они
> хотят, чтобы, например, если пользователь 1 изменил какую-
> то информацию, у других пользователей эти изменения отобразились
> автоматом без лишних телодвижений с их стороны.

Начитались, блин фантастики.

← →
antonn © (2012-01-09 01:59) [5]

> Dmitry1987 (09.01.12 01:04)

не сказано про клиента (в смысле софт), делали web-интерфейс и там аяксом переодически запрашивали изменения с сервера, и обновляли гриды. Но там специфика была такая, что частота опроса раз в 2 секунды была достаточна.

← →
Petr V. Abramov © (2012-01-09 02:14) [6]

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

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

← →
antonn © (2012-01-09 02:19) [7]

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

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

← →
Petr V. Abramov © (2012-01-09 02:35) [8]

> Я вот стал привыкать на работе к почте которая сама "сыпется",

это то самое специфическое исключение - новая почта требует действия (прочитать, забить)

> Сидит работник, орудует степплером, а новые строки сами
> "доставляются" :)

и нафига они ему? нефиг от степлера отвлекаться.

← →
Германн © (2012-01-09 02:58) [9]

> antonn © (09.01.12 01:59)

> Petr V. Abramov © (09.01.12 02:14) [6]

И вы считаете, что поняли нужды автора?
Троешники!

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

У нас реализовано то, что надо автору. Правда, для связки Flex-Java. Уведомления мгновенно приходят по RTMP (red5), никаких пингов и прочих извращений, число пользователей практически неограничено. Судя по комментариям, такого в Delphi еще долго не будет...

← →
DVM © (2012-01-09 10:58) [11]

> Компромисс © (09.01.12 10:43) [10]

> число пользователей практически неограничено

"нам то не гони" (c)

> Судя по комментариям, такого в Delphi еще долго не будет.
> ..

Вот причем тут Delphi? И в Делфи легко прикручивается та же librtmp.dll и шли себе уведомления сколько влезет. Только метод странный какой то.
Да, в делфи еще долго не будут применять протокол для передачи медиаданных (причем закрытый, проприетарный, неизвестно как еще там с лицензиями на его версию, сделанную энтузиастами по неполной документации от Adobe), в бухгалтерских программах.

← →
DVM © (2012-01-09 11:02) [12]

Если уж очень хочется уведомлений, то логичнее всего посмотреть на то как это сделано в Extended MAPI у MS. Ни для кого не секрет, что тысячи пользователей MS Outlook практически мгновенно получают уведомления о приходе/удалении/перемещении писем в своих почтовых базах, причем они не делают постоянных перезапросов к базе Exchange. Уведомляет их сервер через UDP, на уведомления лишь надо подписаться. Сами пакеты, содержащие информацию очень компактны и клиентов может быть очень много.

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

Если так все критично, можно заюзать Notification Services.

← →
Компромисс © (2012-01-09 11:21) [14]

DVM ©

Red5 with AMF calls less than 1024 bytes every second or so can support 20,000 clients in its sleep.
It is scaled easily also.
Red5 has GNU Lesser General Public License.
К слову, Adobe в курсе насчет использования Red5 одним из наших клиентов и никаких претензий не предъявляет.

> И в Делфи легко прикручивается та же librtmp.dll и шли себе
> уведомления сколько влезет.

Замечательно. Тогда я извиняюсь перед Delphi. Надо было сразу "наехать" персонально на некоторых комментаторов, вопрошающих "зачем это надо" :)

← →
DVM © (2012-01-09 12:03) [15]

> Компромисс © (09.01.12 11:21) [14]

> Надо было сразу "наехать" персонально на некоторых комментаторов,
> вопрошающих "зачем это надо" :)

Да вроде бы наехали на Delphi, совершенно безосновательно. RTMP ведь не заслуга Java или Java сообщества.

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

← →
Омлет © (2012-01-09 13:07) [16]

> Я же все равно вижу затею с немедленным уведомлением пользователей
> об изменениях в базе сомнительной

Задачи разные бывают. Такие широковещательные рассылки иногда нужны.

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

DVM © (09.01.12 12:03) [15]

> Да вроде бы наехали на Delphi, совершенно безосновательно.

Согласен. Моя реплика была вызвана "Начитались, блин фантастики."

> RTMP ведь не заслуга Java или Java сообщества.

Ну, red5 (причем абсолютно бесплатно) - заслуга именно Java сообщества. Точнее, авторов red5, которая написана на Java.

> Я же все равно вижу затею с немедленным уведомлением пользователей
> об изменениях в базе сомнительной

Почему? Если у пользователя загружена только что отредактированная запись, почему бы ее сразу не показать в актуальном виде? Во избежание проблем с повторным редактированием. Кстати, данные о том, что другой пользователь начал редактировать какую-то запись, тоже можно передавать по RTMP.

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

> Надо было сразу "наехать" персонально на некоторых комментаторов, вопрошающих "зачем это надо" :)
от того "зачем", часто зависит "как, и можно/нужно ли вообще".
т.что ты и тут с наездами некстати.

← →
Компромисс © (2012-01-09 14:48) [19]

sniknik © (09.01.12 14:34) [18]

Перечитай [0] и пойми, что здесь не тот случай. Совершенно справедливое требование пользователей.

← →
Petr V. Abramov © (2012-01-09 15:07) [20]

> Компромисс © (09.01.12 14:48) [19]

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

← →
antonn © (2012-01-09 15:10) [21]

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

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

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

Petr V. Abramov © (09.01.12 15:07) [20]

Хорошо, допустим, Вы правы и у них "фиговая организация работы". Что Вы предлагаете ТС? Идти к генеральному директору и требовать, чтобы он всё поменял?

← →
sniknik © (2012-01-09 15:26) [23]

> Перечитай [0] и пойми, что здесь не тот случай.
Перечитай [0] и пойми, что здесь вообще нет случая

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

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

← →
sniknik © (2012-01-09 15:28) [24]

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

← →
sniknik © (2012-01-09 15:30) [25]

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

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

sniknik © (09.01.12 15:26) [23]

см. [22].

← →
sniknik © (2012-01-09 15:32) [27]

> см. [22].
см. [24].

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

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

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

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

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

> Если есть необходимость
наводящий вопрос "а зачем?" как раз и проясняет эту необходимость.

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

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

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

> Dmitry1987 (09.01.12 01:04)
> Программой пользуются 2-
> 3 тыс. людей, большинство из них бесит такой подход, они
> хотят, чтобы, например, если пользователь 1 изменил какую-
> то информацию, у других пользователей эти изменения отобразились
> автоматом без лишних телодвижений с их стороны.

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

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

объясни, и я полностью - ЗА!

ты менеджер? чего делаешь на сайте программистов?

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

но по сути, ты бы сделал?

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

А как порадует их постоянное мельтешение данных на экране, со скоростью выше чем глазом можно отфиксировать :)

Почему постоянное? На экран влезает несколько десятков строк всего, нежули все 3 тысячи пользователей постоянно их редактируют? :)

> А как будет рад владелец сервера от возросшей в разы нагрузки
> из-за генерации веером сообщений на каждый чих
> А какое спасибище скажут сисадмины -можешь и не унести такое
> спасибо.

А это клиента не волует и не должно волновать

нежули = неужели
волует = волнует

> Компромисс © (09.01.12 15:58) [33]
> ты менеджер? чего делаешь на сайте программистов?
>
> Я не менеджер, но точно знаю, что если бы мы отказались
> делать так, как хочет клиент, он бы просто обратился к другой
> фирме.

Еще раз - 2-3 тысячи пользователей. Вполне вероятно что в тебении секунды более 25 пользователей будут терзать один и тот же набор данный а 26-й на том же наборе пытатся смотреть кино. И сделать так ибо клиент это хочет?

> А это клиента не волует и не должно волновать

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

> И сделать так ибо клиент это хочет?

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

> Компромисс © (09.01.12 15:58) [33]

В шумном балагане любит веселиться И пожрать отменно радостный народ. Левка-Паганини, если разозлится, Он своею скрипкой всех с ума сведет. А если сунуть четвертак, Так он сыграет и не так.
;)

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

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

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

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