Форум: "Базы";
Текущий архив: 2007.08.19;
Скачать: [xml.tar.bz2];
ВнизПрошу помощи у специалистов по БД Найти похожие ветки
← →
Германн © (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-)
← →
Evgeny V © (2007-05-03 15:50) [11]
> Sergey13 © (03.05.07 15:31) [10]
Согласен, в простых случаях кнопка обновить, о чем в принцие я и говорил в [7] Но по таймеру не так сложно реализовать рефреш как полный
> (а чем это отличается от кнопки обновить?)
, так и только обновлений... У нас правда ситуация совсем простая, нет удалений в базе, клиент не может удалять из базы, и в этом случае все решается одним запросом с параметром. Упрощенно так
select * from table where поле_датавремя_изменение_записи >= :макс_датавремя. Поле конечно вносится в таблицу и проставляется триггером.
Но согласен, некоторый механизм требуется, запоминания даты и прочее... Но иногда это надо и не сказал бы, что это очень сложно и много писать.
Но кнопка обновить и событие OnTimer при полном рефреше - суть в этом случае одна:-)
← →
atruhin © (2007-05-03 16:05) [12]> Идея не плохая, только реализация будет сложнее, чем просто
> поставить таймер,
А чем сложнее то. Инкриментировать поле про достижении ЧЧЧ послать эвент.
3 строчки
← →
Evgeny V © (2007-05-03 16:16) [13]
> atruhin © (03.05.07 16:05) [12]
Нет не так просто,это только часть работы, а если число обновлений не достигло нужного количества за полчаса? Не показывать обновления и не посылать алерт (event)? Приходим дополнительно к таймеру, который проверяет, что мы не ждем новых эвентов слишком долго... Таймер или job есть не во всех СУБД, а потому на стороне сервера прийдется желать это как сервис или реализовать на стороне клиента.....
Впрочем, возможно есть другие реализации - это я на вскидку подумал как решить проблему с алертами на сервере...
На мой взгляд проще один таймер или в самом простом случае таки кнопка. Но если у автора клиентов по пальцам, как он пишет и внесение изменений в базу мало за единицу времени, то просто алерт думаю ему подойдет
← →
Германн © (2007-05-03 17:08) [14]
> Но если у автора клиентов по пальцам, как он пишет и внесение
> изменений в базу мало за единицу времени, то просто алерт
> думаю ему подойдет
>
Так и есть. Спасибо за советы.
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2007.08.19;
Скачать: [xml.tar.bz2];
Память: 0.49 MB
Время: 0.045 c