Как оповестить клиентов СУБД об изменении данных?

Есть клиент-серверное приложение. Delphi + MySQL 5.5.9.
Как реализовать оповещение (перечитать данные) всех клиентов присоединённых к БД в данный момент времени при изменении данных в таблицах. Если один из клиентов изменил данные, у других подключенных клиентов они должны обновиться.

0

Глупости

0

Сообщение от MsGuns Глупости

В самом общем случае, да, глупости! Но иногда (именно иногда) такие вещи делают. Ну, например, фрмируется табло задержки рейсов и обновление набора данных по задержанным рецсам можно формировать в зависимости от событий изменения информации по задержанным рейсам. Удобным механизмом для реализации такого рода задач является механизм событий (Events). На таблицу, в которой необходимо фиксировать изменения вешается триггер афтерапдэйт и в нем генерируется событие. В приложении специальный объект принимает извещение о событиях и обрабатывает их.

0

Это да. Только вот 99% подобных топиков возникает у бывших "локальщиков" и происходит от непонимания сути предметной области и неверно спроектированной бизнес-логики БД. И приходится такому товарищу доказывать, что если Маня поменяла в накладной кол-во отпущенной соли, то это не значит, что у всех 999 операторов, сидящих на этой же базе (причем не факт что сидят они в накладных") должны возникнуть какие-то "обновления". Тем более что сервер ни сном не духом не ведает чем конкретно занимаются эти тыща операторов

Добавлено через 3 минуты
Опять же "табло задержки рейсов" замечательно может обновляться перечитывая НУЖНЫЙ ФРАГМЕНТ базы по таймеру вполне самостоятельно. При этом сервер не будет отвлекаться черт-те-на-чё.

Добавлено через 47 секунд
В общем пример привели неубедительный. Мягко говоря

0

MsGuns, почему не убедительный? Вполне себе пример. И вас же никто не заставляет уведомлять клиентов о каждом чихе в базе данных. Просто могут быть реально важные данные, об изменении которых нужно сообщить всем клиентам.

0

вставляем в таблички поле new boolean (обзови по желанию), устанавливаемое соответствующим триггером в единицу при обновлении таблиц(ы). Сервер время от времени проверяет записи WHERE new и пересылает данные клиентам. После рассылки new в этих записях возвращается в ноль, а сервер переходит к сл. итерации.

0

Сообщение от MsGuns Опять же "табло задержки рейсов" замечательно может обновляться перечитывая НУЖНЫЙ ФРАГМЕНТ базы по таймеру

Ну, в данном случае дискуссия на уровне кто "красивше" и желанней: поп, попадья или попова дочка. Я полностью согласен в том, что глупостью является любая попытка рассылки сообщений "о каждом чихе". Это тем долее верно для больших БД с большим кол-вом объектов и не хилым числом одновременно работающих юзеров.
Если говорить о примере, который я привел с табло, то надо понимать, что частота событий отложений рейсов может быть очень небольшой и тогда при обновлении этой инфы по таймеру будет много "холостых выстрелов".
Мы у себя используем подобную технологию при регистпции лиц, прибывающих в течении рабочего дня на различные мероприятия. Количество таких мероприятий в течении дня несколько десятков. Должностное лицо, которое проводит мероприятие должно иметь точную информацию в момент начала мероприятия о дицах, зарегистрированных для участия в этом конкретном мероприятии. Причем до 90% лиц регистрирутся в течении 30 минут утром и в середине дня, остальные в течение дня. ИМХО для такого случая технология, основанная на Events, подходит идеально.

0

Вы не правы, ув. SAMZ !
Конечно, можно найти предметные области, где мониторинг сервером своих клиентов весьма актуален, но это такое...
В подавляющем большинстве же случаев сервер не обязан заморачиваться подобными траблами по той же причине по которой машинист тепловоза не должен бегать по вагонам и проверять все ли пассажиры расселись согласно купленным билетам а если обнаружатся те, кто отсутствует, то бежать на вокзал и давать "молнию" опаздывающему, мол ты где, отправляемся через 15 мин !
Еще пример: интернет. Вот я запостил сейчас это сообщение и ВСЕХ, КТО СЕЙЧАС НА ФОРУМЕ, сервер должен оповестить, заставив перечитать соотв.странички (причем независимо от того, совпадают ли они с измененной).
Абсурд ? Вот и я об этом же

0

Сообщение от MsGuns Еще пример: интернет. Вот я запостил сейчас это сообщение и ВСЕХ, КТО СЕЙЧАС НА ФОРУМЕ, сервер должен оповестить, заставив перечитать соотв.странички (причем независимо от того, совпадают ли они с измененной). Абсурд ? Вот и я об этом же

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

1

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

0

MsGuns, ок, а если время отправления поезда изменилось, то что будет проще: один раз машинисту уведомить всех или если все пассажиры будут забегать к нему и спрашивать "а чо стоим?"? В плане нагрзуки на сервер, что легче - один раз сгенерировать сообщение для тысячи пользователей или ответить на 1000 запросов?

0

И еще в нагруку.
Чтобы сервер сообщил о событии - этого явно недостаточно, надо чтобы клиент "услышал", т.е. либо должны использоваться при проектировании спец. компоненты, либо приложение должно постоянно "прослушивать" сервер, посылая туда запросы, а получив ответ еще разобраться каксается ли событие, о котором сообщает сервер, его лично. А это лишняя логика, как мне думается вовсе не примитивная.

Добавлено через 6 минут
Ответить на 1000 запросов однозначно. Потому что главное задача сервера - именно отвечать на запросы, а НЕ РЕШАТЬ КОМУ И ЧЕГО ОТПРАВЛЯТЬ БЕЗ ВСЯКИХ ЗАПРОСОВ.
По поводу поезда и логики.. Чтобы машинист или начальник поезда ходил и кого-то в чем-то упреждал.. И причем тут задержка поезда - я о ней не слова не говорил - поезд отходит ВОВРЕМЯ, т.е. даже по вокзальному радио ничего не скажут, например "Поезд № 102 Москва-Мухосранск" отправляется через 5 мин. Пассажиры Пупкин и Лупкин, поторопитесь, иначе поезд уйдет без вас !"
Похоже, Вы слишком давно не путешествовали по ж/д

0

Есть всё-таки случаи, когда есть смысл в оповещении сервером своих клиентов. Например, если готовится перезагрузка сервера (возможно, незапланированная ранее). В этом случае было бы весьма полезным разослать оповещения, чтобы клиенты могли подготовиться к этому событию - зафиксировать или откатить транзакции, например.
---
В Oracle есть специальные механизмы для отправки сообщений клиентам. Используются пакеты: DBMS_ALERT и DBMS_PIPE.
Вот, например, что об этом пишет Том Кайт (второй том). - Надо перейти по этой ссылке, прокрутить текст немного ниже и начать чтение с параграфа: "Пакеты DBMS_ALERT и DBMS_PIPE" и далее.
Ссылка на начальную страницу - Том Кайт, книга 2.

0

Не только в Оракле. Но вот что интересно: после рассылки широковещательного сообщения общего плана сервер по истечении времени просто закрывает соединения, завершая текущие транзакции (в соответствие с указанными в соединениях опциями то ли откатывая, то ли подтверждая), не дожидаясь никаких подтвердений/возражений от клиентов ! Т.е. связь в любом случае ОДНОСТОРОННЯЯ. Другими словами серверу пофих клиент, как тому машинисту опоздавший пассажир. Дал себе гудок, выждал 3 минуты и поехал себе..

Добавлено через 3 минуты
И это "пофих" своего рода "фича" КС-технологии, я бы сказал часть идеологии.
ТС же желает сделать что-то вроде парадокса, в котором рефреш "зашит". Пользоватешль просто привык к тому, что пока он сходил в туалет, на экране появилось все, что успели ввести все его коллеги. Знакомо. Сам с этим сталкивался, было время.
Вообще должен сказать что переход с "локалок" на КС требует революции в мозгах. Во всяким случае со мной было именно так

Добавлено через 5 минут
Там в числе прочего написано про DBMS_ALERT, что клиент должен опрашивать или быть в состоянии ожидания сообщения от сервера. Я об этом выше указывал. Т.е. клиент должен быть "особым". О чем опять-таки было говорено.

0

Сообщение от MsGuns Там в числе прочего написано про DBMS_ALERT, что клиент должен опрашивать или быть в состоянии ожидания сообщения от сервера. Я об этом выше указывал. Т.е. клиент должен быть "особым". О чем опять-таки было говорено.

Ну это да, согласен. Вообще, возможно, удобнее было бы этот механизм реализовать на уровне сервера приложений. Можно самостоятельно реализовать механизм с регистрацией событий и подпиской клиентов на получение извещений при их возникновении. - Это на уровне <сервер приложений - клиенты>. В этом случае, для взаимодействия с сервером БД на предмет извещений через DBMS_ALERT понадобится только один сеанс: <сервер приложений - БД сервер>.

0

А теперь "помечтаем":
Допустим, есть проект программы "Торговый дом", в котором есть "Склад", "Товары", "Покупатели" и "Счета-фактуры". Программа предоставляет интерфейс выписки счетов и установлена на N ПК, с которых одновременно идет выписка. При этом нельзя допустить чтобы был выписан "Товар", которого нет на "Складе". С ПК №1 выписывается товар - "Флэшка" в кол-ве M, соответственно на складе остаток снимается и допустим уходит в 0. Значит с остальных ПК эта флэшка выписана быть не может, правильно ? Так то оно так, но за секунду (2,3..) до того, как с ПК №1 ушла команда серверу на списание, на ПК №2 оператором тоже была выбрана эта же флэшка, но он (оператор) отвлекся на пару минут и на его экране остался старый остаток ! И он иничего не подозревая выписывает товар !
Чтобы этого не произошло (выписки повторно товара, который кончился) мы должны что-то предпринять !
Первое, что приходит в голову, например, ТС - это оператор ПК №2 должен был быть ПРОГРАММНО УВЕДОМЛЕН о том, что флэшка ушла СРАЗУ ЖЕ после того, как сервер обнулил остаток в базе !
Казалось бы логично. А вот и нет !!! При ближайшем анализе и рассуждениях вылазит что:
а) откуда сервер знает, что оператор ПК №2 выписывает именно эту же флэшку, ведь на складе флэшек масса, просто они по другой цене ? Значит, он должен оповестить не только ПК №2, но ВСЕ подключенные к нему ПК (а собсно почему ПК, на одном ПК может быть загружено 10 экземпляров этой программы, да и в одной программе может быть открыто 10 соединений с сервером - в многопоточных приложениях, например апп-серверах, это обычное дело), которых может быть десятки, при этом половина из них стоит в бухгалтерии и там вообще работают совершенно с другим разделом программы.
б) программы на ВСЕХ ПК должны быть в состоянии ожидания от сервера подобного сообщения, т.е. либо беспрестанно опрашивать (фактически "дергать") сервер типа "ну что-там в тайге, все в порядке ?", либо попросту "зависать" и "отвисать" только получив о сервера соббщение, обработать его (в случае с флэшкой на ПК №2 сдалать недоступной соотв. позицию в прайс-листе или даже закрыть модальную форму, открытую оператором кнопкой "выписать") и затем снова благополучно "зависнуть". Можно себе представить что скажут операторы увидев такое чудо программерской мысли
в) есть смысл использовать механизм "прослушки" сервера в тех случаях, когда пишется программа-"баннер", ну что-то вроде табло "отправление поездов" или "Диспетчер задач", т.е. программ, у которых если и есть обратная связь, то очень незначительная (сравним с программой выписки счетов, в которой оператор стросит на клаве беспрестанно, посылая базе десятки запросов в минуту.

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

0

По поводу борьбы за одну и ту же флешку, лучше, наверное, применить старый добрый способ - добавить поле STATE, в которое записывается состояние записи. В случае если состояние = "занято", значит дальнейшие действия в отношении этой записи сеанс проводить не имеет право. Это лучше заложить в бизнес-логику сервера. Состояние "занято" выставляется в самом начале - когда оператор N-го ПК принял решение (и нажал в клиенте соответствующую кнопку), что флешка будет продана через его точку. Остальные клиенты, кто не успел занять флешку, но попытался сделать получат ответ от хранимой процедуры - False (занять запись не удалось). Это позволит каждому клиенту сразу определять - успел он занять флешку или нет. Так по крайней мере, часто реализовывается в системах документо-оборота в отношении, например, файлов документов (и других объектов). Там могут быть состояния - занято, в архиве, удалён и пр. Тут ещё ID сенса или ID пользователя возможно, потребуется для выполнения дальнейших действий над занятой записью.

0

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

0

Ок, господа. Предположим продавец выписывает флешку и кто-то параллельно пытается выписать её же. Флешка на складе одна. Во время выписки произойдет уменьшение количества товара в базе, оно изменится на 0. Ведь можно же добавить триггер на изменение в базе, который будет ругаться, если товара стало 0 и сгенерит эксепшн? Тогда накладную выпишет тот, чей запрос первым будет обработан сервером. Разве так не честнее и проще?

0