Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

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

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

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

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

Германн (2007-05-03 17:08:00) [1]

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

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

Evgeny V (2007-05-03 16:16:00) [2]

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

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

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

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

atruhin (2007-05-03 16:05:00) [3]
> Идея не плохая, только реализация будет сложнее, чем просто
> поставить таймер,

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

Evgeny V (2007-05-03 15:50:00) [4]

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

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

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

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

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

Evgeny V (2007-05-03 15:19:00) [6]

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

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

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

atruhin (2007-05-03 14:44:00) [7]
> Тогда все равно надо делать механизм накопления алертов,
> что бы потом реагировать сразу на все пришедшине, а не
> каждый...

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

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

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

Evgeny V (2007-05-03 13:35:00) [8]

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

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

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

ANB (2007-05-03 12:01:00) [9]

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

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

Виталий Панасенко (2007-05-03 11:58:00) [10]

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

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

Sergey13 (2007-05-03 08:56:00) [11]
> [0] Германн © (03.05.07 01:17)
> Это неудобно.

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

atruhin (2007-05-03 06:03:00) [12]
Не указал какие компоненты доступа используешь. Для BDE, IBX и FIB многие вещи и рекомендации различны.

Зюзя (2007-05-03 02:55:00) [13]
1. По-сложному: Табличку синхронизации завести.
Попроще: Одну маленькую табличку,в которой одна единственная запись с TimeStamp.

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

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

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

Германн (2007-05-03 02:08:00) [14]

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

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

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

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »