Прошу помощи у специалистов по БД

← →
Германн © (2007-05-03 01:17) [0]

Сразу извиняюсь, что нарушаю правила по формулированию темы сообщения. Ну не могу её "правильно" сформулировать. Не возражаю против перенесения её в "Начинающие", но решил, что будет лучше, если она первоначально засветится именно в "Базах".
Опять меня, железячника, просят (начальник просит) доработать программы ушедшего от нас человека. Большую часть его просьб (кстати весьма логичных) я готов реализовать собственными силами. Но вот две из них для меня очень сложны из-за моей некомпетентности в данной области:
1. в системе работают несколько МП. Возникает проблема, связанная с тем, что на одном РМ пользователя уже ввели, а на другом РМ этого пользователя не видно – надо нажать обновление. Это неудобно. Надо предложить вариант, когда обновление происходит автоматически. При этом учесть тот факт, что при обновлении пользователь МП может в это время вводить данные. Они не должны потеряться. Обсуждая варианты, пришли к пониманию, что если нельзя сделать полную автоматизацию, то вполне устроит вариант, когда есть признак наличия обновления в БД (например, в трее вывести. Или еще как… всплывающее окно о наличии обновления. Жмешь ОК – сразу обновляется. Жмешь отложить – на совести пользователя).
МП - программа работающая с базой. РМ - рабочее место, где эта программа работает.
2. Можно ли проверять соединение с БД? Механизм FireBird предусматривает сей процесс. (но при обрыве локальной сети ругани нет. Сейчас проверил).

Прошу советов по данным пунктам. Ссылки на "умные книжки" допускаются, но читать эти книжки у меня пока нет ни времени, ни желания. Хотелось бы получить либо советы, либо ссылки на обсуждения подобных тем.

P.S. Уточню диспозицию. Клиентов мало. Пальцев одной руки более чем достаточно.

← →
Германн © (2007-05-03 02:08) [1]

> на одном РМ пользователя уже ввели, а на другом РМ этого
> пользователя не видно

Читать как "на одном РМ запись уже ввели, а на другом эту запись не видно."

Блин. Ну и получит же он завтра!!!

← →
Зюзя (2007-05-03 02:55) [2]

1. По-сложному: Табличку синхронизации завести.
Попроще: Одну маленькую табличку,в которой одна единственная запись с TimeStamp.

При записи данных в БД, вносить изменения в таблички.

В ходе работы, с некоторой периодичностью, читать данные из табличек и использовать по назначению.

2. А вот когда будет это "периодическое чтение табличек" - вот тогда она и вывалится, ругань эта.

← →
atruhin © (2007-05-03 06:03) [3]

Не указал какие компоненты доступа используешь. Для BDE, IBX и FIB многие вещи и рекомендации различны.

← →
Sergey13 © (2007-05-03 08:56) [4]

> [0] Германн © (03.05.07 01:17)
> Это неудобно.

Неудобно штаны через голову надевать. А запросить обновление информации кнопкой - это самый прогрессивный подход при работе с БД в 99% случаев.

← →
Виталий Панасенко © (2007-05-03 11:58) [5]

> 1. в системе работают несколько МП. Возникает проблема,
> связанная с тем, что на одном РМ пользователя уже ввели,
> а на другом РМ этого пользователя не видно – надо нажать
> обновление. Это неудобно

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

← →
ANB © (2007-05-03 12:01) [6]

> А запросить обновление информации кнопкой - это самый прогрессивный
> подход при работе с БД в 99% случаев.

+1
А для уведомления, если использовались компоненты с вкладки InterBase, то там есть компонент TIBEvents.
Во всяком случае, в оракле эта фича работает корректно (см. ODAC, TSmartQuery) - там даже обновления аккуратно появляются.
Рефрешить же по таймеру весь набор данных - хреново как для сервера, так и для пользователя.

← →
Evgeny V © (2007-05-03 13:35) [7]

> ANB © (03.05.07 12:01) [6]

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

Так что я за алерт(Alert, Event....), когда он возниакет не часто, а так таймер или кнопка. Получать (рефрешить) по таймеру весь набор данных необязательно, достаточно получить обновления.

← →
atruhin © (2007-05-03 14:44) [8]

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

Ну так и делай только на сервере.

> А для уведомления, если использовались компоненты с вкладки
> InterBase, то там есть компонент TIBEvents.

Согласен. Только все зависит от версии сервера и от версии компонент.
На старых версиях и сервера и компонент глючило, в Firebird исправили с IBX не работаю не знаю.
Поэтомы и спрашивал в > [3] atruhin © (03.05.07 06:03), но видимо автору уже не актуально.

← →
Evgeny V © (2007-05-03 15:19) [9]

> atruhin © (03.05.07 14:44) [8]

> Ну так и делай только на сервере.

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

← →
Sergey13 © (2007-05-03 15:31) [10]

> [7] Evgeny V © (03.05.07 13:35)
> Получать (рефрешить) по таймеру весь набор данных необязательно,
> достаточно получить обновления.

Потом еще приделать механизм, кторый будет определять - а нужны ли обновления для открытых у клиента данных. А потом проверить как часто обновления применяются (т.е. тот механизм работает). Потом удостовериться, что обновления на самом деле и не нужны вовсе, и только нагружают и клиента и сервер. Плюнуть на все и вернуться к кнопке "Обновить". 8-)

> Sergey13 © (03.05.07 15:31) [10]

Согласен, в простых случаях кнопка обновить, о чем в принцие я и говорил в [7] Но по таймеру не так сложно реализовать рефреш как полный
> (а чем это отличается от кнопки обновить?)
, так и только обновлений... У нас правда ситуация совсем простая, нет удалений в базе, клиент не может удалять из базы, и в этом случае все решается одним запросом с параметром. Упрощенно так
select * from table where поле_датавремя_изменение_записи >= :макс_датавремя. Поле конечно вносится в таблицу и проставляется триггером.
Но согласен, некоторый механизм требуется, запоминания даты и прочее... Но иногда это надо и не сказал бы, что это очень сложно и много писать.

Но кнопка обновить и событие OnTimer при полном рефреше - суть в этом случае одна:-)

> Идея не плохая, только реализация будет сложнее, чем просто
> поставить таймер,

А чем сложнее то. Инкриментировать поле про достижении ЧЧЧ послать эвент.
3 строчки

> atruhin © (03.05.07 16:05) [12]

Нет не так просто,это только часть работы, а если число обновлений не достигло нужного количества за полчаса? Не показывать обновления и не посылать алерт (event)? Приходим дополнительно к таймеру, который проверяет, что мы не ждем новых эвентов слишком долго... Таймер или job есть не во всех СУБД, а потому на стороне сервера прийдется желать это как сервис или реализовать на стороне клиента.....

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

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

> Но если у автора клиентов по пальцам, как он пишет и внесение
> изменений в базу мало за единицу времени, то просто алерт
> думаю ему подойдет
>

Так и есть. Спасибо за советы.

Прошу помощи у специалистов по БД Найти похожие ветки