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

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

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

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

Отсюда два вопроса:
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

Спасибо.