Есть проблема в синхронизации данных между несколькими клиентами.
Клиенты имеют списки, например: список неиспользованных бланков, список договоров и т.д., которые загружаются из БД.
Например, один клиент резервирует бланк или добавляет страховую компанию.
Второй клиент должен это отобразить.

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

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

В общем-то, такая задача, наверное, достаточно распространена.
Но вот я не знаю откуда подступиться.

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

http://www.postgresql.org/docs/8.4/static/sql-listen.html
Блин, забыл. У меня MySQL. Там нет LISTEN. :-( Сменить СУБД не могу. Во-первых, под неё уже почти всё написано, а времени нет.
Во-вторых, на ней старая база.

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

резервироватьх.
Только пример. Есть дерево компаний. Компании выдают пустые бланки с номерами.
Бланки отображаются в дереве.
Иногда администратор может добавлять/удалять/изменять компании.
Это должно отобразиться у всех пользователей.
Любой пользователь может завести договор, использовав пустой бланк.
Бланк предварительно резервируется. Когда бланк использован или зарезервирован,
он должен исчезнуть из дерева.

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

блокировать?
Это про бланки.

оповещение по изменению данных есть во всех "больших" серверах
В MySQL, похоже, нет. Хотя, может, я плохо искал.

плюнь - пусть кнопаку "Обновить" жмут
Учитывая, что времени в обрез, а написано где-то две трети - предложение вполне разумное.
Но, по идее, - это не вариант.

Долго будет производиться полное обновление.

- В каждом ЯП есть виртуальные деревья - подзапросы на канкретные ветки при действиях пользователя.
Хм.. Т.е., при раскрытии ветки? А, если ветка уже раскрыта? Проблема-то в этом...
Ведь придётся по всему дереву проходить и проверять что обновилось/удалилось/изменилось..?
Плюс, там же много списков и элементов отображения.
Надо проверять есть ли такой элемент в списке, обновился ли, или удалён из БД.

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

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

Или таблица 1-5 Кб. Вполне приемлемо.

- ну и сервер узнать надо "на форуме сервера"
Предлагают написать это, как функцию на компилируемом языке. :-\

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

Да, сейчас размер справочников ~200 Кб на диске. Причём, БД ещё не полностью переделана на InnoDB.

2Petro123 :

чё ты всё усложняешь?
Дык, как всегда...

- если надо экономить трафик, то на триггер повесь аудит
Про то и думаю. Вот только, на какой триггер? Придётся для каждой таблицы...
Хотя, есть ещё планировщик. С помощью него возможно запускать процедуру "централизованно" через интервал.
Но тут, - хуже, я думаю.

- на клиенте читай эту таблу аудита с параметром "оповещать через N секунд"
По таймеру?

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

- наверху формы бегущая строка - "изменился справочник AAAA"
Хм... По-идее, возможно...

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

ЗЫ. Любят программисты всё решать за пользователей.
Не равняйте по себе. Пользователи, в основном, - девушки-юристы (ну или как правильно)?
Зачем возлагать на них нагрузку по решению вопроса о загрузке справочника?
С другой стороны, не должно быть "томрозов" и мельканий, при работе... :-|

Ты на форуме сам жмёшь F5 ?
Я терпеть не могу, когда система что-то делает за меня.
Но браузер - это браузер. А, даже Far взять.
Представьте, что если бы в одной панели вы что-то удалили, а вторую пришлось обновлять вручную?
Неудобно. Здесь - тоже самое.

Или за тебя решил MS ?
У меня firefu**s.


prolis :
Нужно интерфейс пересматривать.
Интерфейс, конечно, придётся потом ещё пресмотреть.
Но кардинальной перестройки я не планирую.

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

Тогда и большие справочники на странице не нужны, и с обновлением нет вопросов.
Там списки, а не всё содержимое справочников.

Опишу, какие задачи я конкретно хочу решить.

Т.е., например, список регионов, список коэффициентов, список марок ТС и т.д.
Например, пришёл клиент, марка ТС, которого не занесена в БД.
Какой-то пользователь, из группы, у которой есть права на изменение справочников,
добавил марку ТС в справочник.
У других пользователей марка ТС должна отобразиться в списке марок.

Есть два случая:
а.) Открытие соответствующего окна ("менеджера ТС").
б.) Окно уже открыто.

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

З1. Как это сделать оптимально?

Следующий пример:
Есть страхователь и владелец ТС и их данные, отображённые в окне.
Есть список водителей.
Водители могут добавляться/изменяться через менеджер клиентов.
В данном менеджере возможно изменить любого клиента, в т.ч. и того, который
является страхователем.
Т.е., в теории, может быть поменян страхователь или владелец.
Надо отобразить изменения. Аналогично со списком водителей.
Отслеживать изменения локально, вряд ли есть смысл, поскольку, в тоже время,
любой клиент может быть поменян любым другим пользователем.

З2. Как решить проблему соответствия отображаемых, локальных и серверных данных?

Аналогично решается и с бланками, и с компаниями и т.д.
Остаётся только понять как и, после сделать. :-\

Да и авторефреш данных, в действительно оперативных системах,
тоже не плохо и не сложно.
Вот только насчёт "несложно"...

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

даже в вэбе грузят справочник на AJAX.
А в клиент-сервере это вообще не обсуждается
Почему это не обсуждается? Потому что "все так делают"?
Это критерий оптимальности? :-\

Petro123- нерационально открывать справочник заранее и искать способы его обновления
Вот тут, пожалуй не соглашусь.
1. Данные открываемого справочника обязательно пригодятся, при пользовании программой.
Пример: регионы. Если пользователь полноценно пользуется программой, он обязательно выберет регион.
Из списка. Регион обязательно будет отображён, как выделенный пункт списка.
Т.е., регионы нужны всегда.
В течение рабочего дня, почти каждый пользователь полноценно пользуется программой.
2. Данные справочника почти никогда не меняются.
Ну когда последний раз добавлялся или изменялся субъект федерации?
3. Пользователей несколько. Справочники весят не очень мало.

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

ps. тут был про это топик (кэш справочников на клиенте)
Я читал. Но там ведь и была описана проблема, связанная с большой нагрузкой на сеть.
В итоге - тормоза.

905может отказаться от громоздких деревьев-справочников ?
все таки они увеличивают мышевозюканье
Ну да, и код проще... Но там наиболее наглядно и удобно - дерево.
Оно единственное в программе. Дерево компаний. Хотя, с ним и проблемы.
Я не придумывал интерфейс с нуля, а взял за основу похожую программу, которая уже лет семь развивается.

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

Блин, не приложился. :(
Вот на df:
http://depositfiles.com/files/tlcihs2gs

Спасибо.

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

более старшая БД
100 % - не вариант, поскольку тогда надо:
1.) Перегонять БД в другую СУБД (а там немало данных, потому и был выбран MySQL – он использовался в старом пакете, работа с пользователями, транзакции, ограничения по внешним ключам и прочие СУБД специфичные вещи).
2.) Переписывать и проверять серверную часть. Поскольку, хранимый код, всё-таки, специфичен.
3.) Немного переписывать клиента.
4.) Изучать новую СУБД.
5.) И т.д.

или оптимизировать кодом до упаду.
Остаётся только это.

А обычная табла в 5 000 записей в сети грузится за 3-5 сек.
С другой стороны, возможен «гибридный» вариант.
Т.е., при изменении справочников полностью их перезаполнять. А изменения отслеживать по триггеру и хранить в отдельной таблице. Т.е., клиентский код упрощается. А, поскольку справочники изменяются редко, обновления также будут очень редкими.
Короче, - обычное кэширование.
К большому сожалению с деревом и вкладкой, которая на скриншоте, проблема не решается. :-(

Вопрос что делать с ними?

Так что страхи твои сильно преувеличены (это тебе не вэб)
Это не «страхи», а стремление сделать по-человечески...

кто мешает показывать правую сторону экрана только:
Так и показывается.

- первый раз при открытии формы вкладка 0
Ну да, только на вкладке 0 тоже есть списки.
Даже, например, список "Класс бонус-малус" на вкладке 1. Если какой-то класс был удалён администратором, нужно перезаполнить список.

Зачем тебе кэш?
Я имею ввиду, кэш, не как отдельную сущность, а как "нормальное состояние".
Т.е., например, "Класс бонус-малус" кэшируется в списке. Список просто не обновляется.
Зачем его обновлять?
Ведь, практически классы уже несколько лет не меняются (разве что, коэффициенты).
Но, теоретически администратор может изменить этот справочник, используя клиент.

Плюс, на вкладке 1, должен обновиться водитель в списке водителей, данные страхователя, данные владельца, при каком-либо их изменении.

Сейчас подумал.

Решил сделать нечто вроде такого:
1.) Сервер.
Триггеры (AFTER) пишут в таблицу обновлений данные.
Имя таблицы.
Ключ записи. Если составной, то разделяется, к примеру, символом ';'.
Время обновления.
Действие или его код: update, insert, delete.

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

2.) Клиент.
Имеется объект "Диспетчер обновлений".
Данный объект реализует:
а.) Автоматическую загрузку таблицы обновлений.
б.) Хранение времени последнего обновления таблиц.
в.) Разбор ключа.
г.) Сравнение времени обновления коллекции сущностей или списка записей с таблицей.
д.) Генерацию событий, оповещающих об обновлении.

Интерфейс подписан на события диспетчера и реализует обновления "отображения".
Коллекции объектов хранят время последнего обновления.

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

Что скажете, стоит подобное делать?

П.2 решает заказчик, т.к. на 20-30 % удорожает систему.

Сколько?!

Есть ещё вариант оповещения если у тебя полный ООП на клиенте
Не полный, но сделать такое не сложно.

ЗЫ. я так понял, что у тебя система перестраивается на ходу админом?
Это тоже просил заказчик? Или твоя фича?
(я бы взял это на доработку\версии)
Моя фича.
Изначально нужно было сделать не столь много: базовую функциональность (БД, печать бланков), напоминания и ограничения.
Плюс, оставить данные БД из предыдущего клиента.
Так вышло, что программа, как раз подошла на диплом.
Т.е. я делаю без ТЗ и договора, и постепенно на меня пытаются навесить:
"А вот бы ещё сделать печать заявлений, а неплохо бы,
чтобы администратор в конце дня одобрял или не одобрял изменения, но это не обязательно,
неплохо бы сделать сводную статистику по договорам."

О цене я предварительно не договаривался. Спросил людей, сказали, что в районе 50 т.р.
Видимо, заказчик на эту цену и рассчитывает...