Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Базы";
Текущий архив: 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
1-1181373282
ambhtr
2007-06-09 11:14
2007.08.19
Выгрузка результатов в Word


15-1184071382
Kolan
2007-07-10 16:43
2007.08.19
Использование DataLayer посоветуйте литературу.


15-1184934390
UMU
2007-07-20 16:26
2007.08.19
Договор на продажу ПО (лицензирование)


2-1185444963
pukin
2007-07-26 14:16
2007.08.19
Динамическая копия набора компонентов


15-1185115628
Rubagl
2007-07-22 18:47
2007.08.19
Книга "Delphi. Готовые алгоритмы. " Нужны исходники.





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский