Синхронизация клиенского приложения с БД.

[Вахмурка]

  Вопрос такой:"Есть многопользовательское приложение с сервером БД, как добиться того, что бы изменения в БД сделанные одним пользователем былы стразу(или почти сразу) видимы в клиентских приложениях другим пользователям?" Одним зи вариантов я как полагаю може быть промоежуточный програмный слой на сервере с БД, который и будет заниматься этим.

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

[RXL]

Можно. Например, сделать табличку, которую клиенты будут периодически опрашивать на предмет изменения какой-нибудь строки. Например такую: CREATE TABLE (name VARCHAR(16), version INT). Соотв., если значение изменилось, то надо обновлять данные.

[Вахмурка]

Можно. Например, сделать табличку, которую клиенты будут периодически опрашивать на предмет изменения какой-нибудь строки. Например такую: CREATE TABLE (name VARCHAR(16), version INT). Соотв., если значение изменилось, то надо обновлять данные.

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

[Алексей++]

Вахмурка, пусть сервер через соединение с клиентом кидает извещение

[RXL]

Нагрузка это незначительная.

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

[Dimka]

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

Такое решение будет в духе ныне модной архитектуры SOA

[Вахмурка]

 Вариант с сервером прикладного уровня в полне подойдёт, только нужно сделать что бы сервер посылал сообщение сначала в БД, а потом случае удачи всем остальным, иначе в случае аварийного отката транзакции, у клиентов будут неправильные данные. Хорошо, все спасибо.

[McZim]

1. Нагрузка на сервер БД будет минимальной.
2. Экономить на тратифке между сервером БД и клиентами это бред.
3. Не выдумывайте ерунды, почитайте как строятся системы с использованием серверов БД.

[Вахмурка]

1. Нагрузка на сервер БД будет минимальной.
2. Экономить на тратифке между сервером БД и клиентами это бред.
3. Не выдумывайте ерунды, почитайте как строятся системы с использованием серверов БД.

Выходит я зря парюсь. Литература есть, только там этот вопрос подробно не затронут. (покрайней мере в той что есть у меня)

[McZim]

Вахмурка, да зря, бред писать прослойки, для создания нормальной системы.

[Dimka]

2. Экономить на тратифке между сервером БД и клиентами это бред.

С чего вдруг такая категоричность в условиях неизвестности требований.

3. Не выдумывайте ерунды, почитайте как строятся системы с использованием серверов БД.

То, что называется "архитектура клиент-сервер", было модно в 90-х годах, а сегодня модно SOA

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

[Sla]

технология ajax'a

Нагрузка невелика, траф невелик. Клиентская часть - невелика.

Вахмурка, посредством СУБД? но клиент как-то должен получить информацию об измене?

[RXL]

SOA дает снижение производительности и увеличивает трудоемкость создания и поддержки системы по сравнению с прямой работой с БД. Плюс - исключается прямая работа клиента с БД.

[Dimka]

бред писать прослойки, для создания нормальной системы.

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

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

[Sla]

самая простейшая синхронизация - IRC сети

[Dimka]

SOA дает снижение производительности и увеличивает трудоемкость создания и поддержки системы по сравнению с прямой работой с БД.

Насчёт трудоёмкости... Такие средства, как, например, WCF.NET, как раз и призваны снизить трудоёмкость за счёт реализации всей инфраструктуры: транспорт, хранение, маршрутизация, приоритеты и т.п. Так что положение улучшается.

[McZim]

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

гы

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

именно!

[Oldy]

Вопрос такой:"Есть многопользовательское приложение с сервером БД, как добиться того, что бы изменения в БД сделанные одним пользователем былы стразу(или почти сразу) видимы в клиентских приложениях другим пользователям?"

С трудом представляю ситуацию, когда это необходимо, разве, что редакция справочников.
Вопрос стоит - "можно-ли реализовать ЭТО средствами БД" т.е. не тонким клиентом и не сервером БД, а именно средствами БД? Я правильно понял? То есть посредствам триггеров или встроенных процедур?


 

[Sla]

Oldy, я думаю, что подразумевается средствами СУБД, возможно с каким-нибудь собственным обвесом.
даже, не берусь утверждать, это можно реализовать на уровне встроенных процедур (вызов со стороны клиента, переход в ожидание)

[Oldy]

Возможен вызов UDF из внешней библиотеки, способной отправить сообщение системе. Некоторые СУБД сами поддерживают такую возможность (отправку сообщений в ОС), как из триггеров так и при подтверждении или откате транзакции.

[Вахмурка]

Возможен вызов UDF из внешней библиотеки, способной отправить сообщение системе. Некоторые СУБД сами поддерживают такую возможность (отправку сообщений в ОС), как из триггеров так и при подтверждении или откате транзакции.

В принципе меня интересует больше именно этот вариант. Отправлять сообщения клиенту об изменениях средствами самой БД.

[RXL]

Вахмурка, средствами _только_ БД клиента оповестить не удастся (если какая-либо СУБД имеет такую возможность, то это исключение, а не правило). Речь о том, что используя некий сервер приложений (к которому подключены все клиенты), можно через внешнюю процедуру послать через этот сервер сигнал клиентам.

[Oldy]

Вахмурка, посмотри статью, вдруг поможет чем-либо: http://www.ibase.ru/devinfo/clientrefresh.htm