| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Синхронизация баз данных [D7, IB6.x, FB]
carmen © (2005-06-02 09:41:00)Суть вопроса в следующем. Я пишу АРМы для водоканала, РЭС, ЖЭК. Программы работают нормально и писались изначально только для местных организаций. Но на самом деле вышло намного лучше, программы были установленны еще в 3-7 (в зависимости о оргинизаций) районах области. Сейчас стала задача имея сервер в области получать данные из районов. Все базы почты идентичны. Имееются таки таблицы как: начисления (автоматически заносяться данные о нормах и суме начисления, а также в ручную коректировки), точки учета (информация о видах начисления), оплата (информация о оплате), сальдо (сальдо абонента на начало текущего месяца) и другие (не большого размера). Названные таблицы имеют большой размер.
Вопрос 1Как можно синхронизированть данные с машины в районе и на машине в области.
Вопрос 2 (не по теме)Может еще кто-то пишет подобные программы, хотелось бы пообщаться.
Заранее благодарен
Qwerty666 (2005-08-01 15:26:00) [1]Занимаюсь подобной фигней для теплосетей. СУБД: MAX DB (разновидность MySQL), язык - Java. СИнхронизация - по модему. Главная фишка РУЧНОЙ репликации - совсем необязательно иметь одинкаовые структуры таблиц в районах и в центральном офисе. А именно: в ц. офисе таблицы должны являться пригодными для использования ВЫБОРКАМИ, ВЫЖИМКАМИ из данных районов (ничего лишнего). Вариантов для однозначной идентификации записей в БД на ц. офисе (буду называть "сервером") - море (номер района+праймэри ки записи на районе+время добавления и т.п.). Но тут лучше придерживаться следующей тактики (работает с удалением): записи всех районов являются ПОДМНОЖЕСТВОМ записей на сервере. Удалять записи на сервере - только всем скопом. Гимор исчезает (и это правильный выход, вспомните, например, правила ведения журналов аудита ПБ). Если интересно - мыльте.
Qwerty666 (2005-08-01 15:25:00) [2]Занимаюсь подобной фигней для теплосетей. СУБД: MAX DB (разновидность MySQL), язык - Java. СИнхронизация - по модему. Главная фишка РУЧНОЙ репликации - совсем необязательно иметь одинкаовые структуры таблиц в районах и в центральном офисе. А именно: в ц. офисе таблицы должны являться пригодными для использования ВЫБОРКАМИ, ВЫЖИМКАМИ из данных районов (ничего лишнего). Вариантов для однозначной идентификации записей в БД на ц. офисе (буду называть "сервером") - море (номер района+праймэри ки записи на районе+время добавления и т.п.). Но тут лучше придерживаться следующей тактики (работает с удалением): записи всех районов являются ПОДМНОЖЕСТВОМ записей на сервере. Удалять записи на сервере - только всем скопом. Гимор исчезает (и это правильный выход, вспомните, например, правила ведения журналов аудита ПБ). Если интересно - мыльте.
Desdechado (2005-07-04 10:57:00) [3][42]
слишком глобальное обобщение
в чем сомнения? чем они подкреплены?
isasa (2005-07-03 14:57:00) [4]Здесь не прозвучало.
Все вышесказанное хорошо для MS SQL или Oracl.
Для Interbase - сомневаюсь
J55 (2005-07-01 17:13:00) [5]carmen
Интересно узнать, к какому выбору Вы все-таки пришли?
Desdechado (2005-06-30 18:29:00) [6]> в магазин за выпиской и закуской
только выписался, и тут же закусывать?!
ну, могём :))
Андрей Жук (2005-06-30 14:16:00) [7]>>Все должно работать автоматом, юзер нажал на одну кнопку, комп набрал модемом номер, завязался с сервером, передал данные, разорвал соединение. Юзеру незачем знать что машина делает чтобы передать данные.
Тогда пиши сервис, который раз в день (или как там нужно) пересылает наверх данные. Для пользователя вообще не видно.
А в центре - тоже сервис, который получает файлы из филиалов и обрабатывает их.
Все имхо, но реализовано и проверено мною.
msguns (2005-06-30 13:53:00) [8]Прежде чем итти в магазин за выпиской и закуской, неплохо бы определиться с компанией.
Если имеется вариант со сбором информации с мест в центр, т.е. в филиалах только вводят данные, причем не повторяющиеся в других филиалах и при этом структура информации идентична, а в центре их лишь объединяют в одно целое для синтетики, причем сбор делается достаточно редко и не влияет на работу филиалов - это одно.
Если же информация филиалов может пересекаться, каждому филиалу постоянно нужны некие данные общего плана и причем в интеракивном режиме, сама информация в филиалах разная по составу и т.д. - это, простите, совсем другое.
В первом случае незачем тратиться на каналы связи, сервера и т.д., тем более, что далеко не всегда имеется даже возможность подключения ПК филиала к телефонной линии, не говоря уже об инете. Единственная проблема - справочники, решается достаточно простым способом, заключающемся в двух аспектах:
1. Существует "глобальный" справочник в Гл.офисе, который пополняется новыми сведениями из каждого очередного "пакета" каждого филиала по определенным алгоритмам.
2. Разработана жесткая система кодирования реквизитов справочника, которую операторы обязаны соблюдать, придерживаемая по возможности встроенным в программу блоком входного контроля.
Мне кажется, что у автора именно такая ситуация.
Desdechado (2005-06-30 13:23:00) [9]> А такое заявление, согласитесь, сбивает с толку. ;)
Уточню - НЕ ОБЯЗАТЕЛЬНЫ надежные каналы. Если они есть, то хорошо. Если нет, не смертельно.
> варианты терминальной работы и стандартной клиент-серверной архитектуры
в случае К-С одни минусы: сложность админ-я, обрывы связи с утратой данных и текущего состояния работы, огромный траффик, сложность обновления
J55 (2005-06-30 12:04:00) [10]Desdechado
/Надежность в классическом виде - это вероятность доставки сообщения получателю без искажений и в заданный промежуток времени.
Применительно к теме - это, на бытовом языке, сможет ли пользователь работать в своей терминальной сессии без потери данных и времени./
Согласен.
/еще раз повторю - для случая терминального сервера НЕ нужны надежные каналы,/
А такое заявление, согласитесь, сбивает с толку. ;)
To All:
Если рассматривать варианты терминальной работы и стандартной клиент-серверной архитектуры с расположением сервера в центре, а АРМ-ов на переферии, то какие плюсы/минусы?
Desdechado (2005-06-30 10:17:00) [11]2 J55
Надежность в классическом виде - это вероятность доставки сообщения получателю без искажений и в заданный промежуток времени.
Применительно к теме - это, на бытовом языке, сможет ли пользователь работать в своей терминальной сессии без потери данных и времени.
Так вот - сможет. А "получасовые пропадания связи" - это авария. Я очень сильно сомневаюсь, что такое имеет место, по крайней мере регулярно. С деревней Замухруевкой такое, может, и возможно, а вот облцентр-райцентр - не верю.
Но даже если такое случится раз в неделю, напишет на бумажке, потом занесет в БД, когда связь восстановится.
Anatoly Podgoretsky (2005-06-30 10:02:00) [12]Приемлемая скорость получается уже при 33кб, рекомендуемая минимальная 64. Все что выше улучшает комфорт.
Понятия одновременная работа, на деле всего лишь мифическое понятие. Никакой одновременной работы как таковой нет, процессы передачи данных дискретны и разнесены по времени. На скорости уже в 128 кб сенасы передачи практически не будут накладываться друг на друга. Если посмотреть на типовую работу оператора, то скорость ввода редко превышает 200 знаков в минут и процесс это не непрерывный, а редкий. 10 буквочек набил и следующие 10 будут не скоро. Достаточно посмотреть на любую типовую работу с Вордом и особенно с Экселем в офисе.
J55 (2005-06-30 09:45:00) [13]Desdechado
А что Вы понимаете под "надежностью каналов связи"???
И так ясно что при обрыве соединения ничего страшного с сервером не случится, только как пользователь работать будет, если ему данные вводить и получать надо, а связи полчаса нет????
Из вопроса автора темы видно, что речи идет о работе в том числе и с квитанциями абонентов в непосредственном с ними контакте и поэтому перерыв в работе даже на 5 мин. будет очень заметен.
Лично я под "надежными каналами связи" понимаю обеспечение соединения, которое не влияет на работоспособность приложения, в том числе и по времени рекции.
На счет пропускной способности способности спорить не буду, главное, что бы хватало. Кстати, какая нужна пропускная способность для одновременной работы 20 терминалов?
Anatoly Podgoretsky (2005-06-29 19:55:00) [14]Desdechado © (29.06.05 19:33) [31]
Может ему будет понятно по другому.
От того что удаленый компьютер отключился от терминальной сессии, терминал продолжает работать. Проверяется легко запускается что то долго играющее, затем отключение, спустя некоторое время подключение и видим, что работа продолжалась.
Да и куда ей деться, поскольку на удаленой стороне только монитор и клавиатура, а выключение монитора никогда не приводило к выключению компьтера. Текстовый вариант терминала называется Telnet. Я в свое время так любил качать файлы по ФТП на сервер, запускал закачку и отключался, чтобы не тратить деньги, а потом спустя некоторое время приходил обратно и уже заказывал закачку к себе на компьютер. Это когда каналы были маленькие, а компьютеры большие.
Desdechado (2005-06-29 19:33:00) [15]2 J55
еще раз повторю - для случая терминального сервера НЕ нужны надежные каналы, НЕ нужны каналы с высокой пропускной способностью
оборванная сессия остается на сервере, к ней можно назад переподключиться, ничего не потеряв
Sergey13 (2005-06-29 16:31:00) [16]2 [29] J55 (29.06.05 16:23)
После беглого прочтения.
Минусы второго также присутствуют и в третьем варианте. ИМХО.
J55 (2005-06-29 16:23:00) [17]Если сделать вывод, из всех советов то в данном случае есть следующие варианты:
1.Один центральный сервер в области и все работают с ним.
Плюсы:нет проблем с репликациями, централизованое администрирование, легкость обновления структуры БД, одна копия БД и АРМ-ов (можно проводить централизованое обновление АРМ-ов ;) и т.п.
Минусы:необходимы надежные каналы связи с хорошей пропускной способностью.
Переработка программы:минимизация трафика.
2.В каждом филиале и центральном офисе стоит одна копия программы и БД (везде структура одинакова). Данные реплицируются в центральный офис.
Плюсы:нет зависимости от каналов связи, одна копия программы и БД.
Минусы:необходимы разработать правила репликации и строго их придерживаться, будет много копий БД -> трудности обновления БД и поддержка одинаковых версий, в одни и теже АРМ-ы придется лепить функции необходимые для центрального офиса и филиалов.
Переработка программы:введение репликации -> скорее всего придется переписать программу, т.к репликация должна быть учтена уже в структуре БД.
3.В каждом филиале стоит версия для филиалов, в центральном офисе стоит версия для центрального офиса со своей структурой БД (далее ЦО).
Плюсы:нет зависимости от каналов связи, программа ЦО может разрабатываться отдельно или даже другим программистом, если в филиалах используются разные программы, то достаточно сделать для каждой экспорт в структуру ЦО и все.
Минусы:разные варианты программ и БД, следовательно все минусы с этим связанные.
Переработка программы:достаточно сделать экспорт :), зато придется писать версию для ЦО ;(.
PS: Все это конечно ИМХО и в зависимости от ситуации плюсы могут быть минусами и наоборот.
У нас сейчас тоже пока стоят перед подобной дилемой (в масштабе области). Но пока наверху стоят проблему придется решать на местном уровне (в масштабе района). Пока склоняюсь ко 2-му варианту.
To: carmen ©
Если интересно все это обсудить то пишите на мыло.
Sergey13 (2005-06-28 10:52:00) [18]2[27] dolmat (28.06.05 10:44)
>>Сейчас стала задача имея сервер в области получать данные из районов.
>Для чего? Какой-то шишке необходимо знать сколько должен гражданин Х? И что из того? Получит нагоняй несколько раз директор а от него работник водоканала после чего работник начнет умышленно искажать данные. Зачем?
Правильно. Всякие сети и прочая централизванная обработка информации - это все фигня от лукавого.
"Это все придумал Черчиль в 18 году" (с)
8-)
dolmat (2005-06-28 10:44:00) [19]>Сейчас стала задача имея сервер в области получать данные из районов.
Для чего? Какой-то шишке необходимо знать сколько должен гражданин Х? И что из того? Получит нагоняй несколько раз директор а от него работник водоканала после чего работник начнет умышленно искажать данные. Зачем?
В принципе пишите лог, в конце дня пользователь его передает на сервер, сервер его обрабатывает. После чего формирует свой лог для клиента и отпрасляет его пользователю. Примерно таким образом работают банки используя для целей приема передачи текстовые файла и систему SFMail (Radius). Количество приемо-передач пока есть чего обрабатывать.
Amerika (2005-06-28 09:26:00) [20]К вопросу 1:
Я так думаю, что в районах вообще не надо держать базу данных, она может оставаться в центре на серваке, доступ через расшаренный ODBC. Пусть переферия звонит по модему и получает доступ к БД, трафик мощный в таком случае не нужен. Если конечно телефонная связь не дорогая
| |
Страницы: 