Синхронизация баз данных

← →
carmen © (2005-06-02 09:41) [0]

Суть вопроса в следующем. Я пишу АРМы для водоканала, РЭС, ЖЭК. Программы работают нормально и писались изначально только для местных организаций. Но на самом деле вышло намного лучше, программы были установленны еще в 3-7 (в зависимости о оргинизаций) районах области. Сейчас стала задача имея сервер в области получать данные из районов. Все базы почты идентичны. Имееются таки таблицы как: начисления (автоматически заносяться данные о нормах и суме начисления, а также в ручную коректировки), точки учета (информация о видах начисления), оплата (информация о оплате), сальдо (сальдо абонента на начало текущего месяца) и другие (не большого размера). Названные таблицы имеют большой размер.
Вопрос 1Как можно синхронизированть данные с машины в районе и на машине в области.
Вопрос 2 (не по теме)Может еще кто-то пишет подобные программы, хотелось бы пообщаться.

Заранее благодарен

← →
Yurij-7 (2005-06-02 09:54) [1]

Использовать репликацию при помощи ТХТ файла например + добавить таблицу ведения протокола репликации (ну например чтобы невтянуть одну и туже инфу 2 раза).

← →
Anatoly Podgoretsky © (2005-06-02 10:04) [2]

Репликация, если в полях есть поле дата модификации и репликация однонаправленая то весьма просто, если не касаться целостности данных.

← →
Zacho © (2005-06-02 10:11) [3]

Почитай http://www.ibase.ru/develop.htm раздел "Репликация"

← →
carmen © (2005-06-02 10:53) [4]

Каждая таблица содержит поле Data_Work, куда автоматом вводится дата и время работи. Если сверку делать по дате работы, то как быть с удаленными записями. Нужно чтобы база в районе и база на сервере были идентичны.

← →
liver (2005-06-02 10:56) [5]

Репликация...
а по поводу втянуть или не втянуть туже инфу, так эт надо юзать разные типы репликации...
если каналы широкие, то можно и втянуть...
а вообще репликация по транзакшинлогу...я так думаю...

← →
liver (2005-06-02 10:57) [6]

упс, сорри, не заметил что про IB6.x, FB вопрос :)
все о MSSQL думаю :)

← →
Sergey13 © (2005-06-02 10:59) [7]

2[4] carmen © (02.06.05 10:53)
>Нужно чтобы база в районе и база на сервере были идентичны.
Это утопия, если инфу вводят постоянно и там и там. Особенно справочники.
Тебе надо, прочитав как можно больше про репликацию, сесть и подумать над структурой БД. Если репликация ранее в проекте не учитывалась, то скорее всего ее придестя значительно дорабатывать.
ИМХО.

← →
Carmen © (2005-06-02 11:14) [8]

Программа и база изначально писались только на одну организация, и никто немог подумать о такой распространенности программы.
Справочники обновляются очень редко. В основном изменеются таблицы с оплатой, субсидиями (один раз в конце месяца), точки учета, показания счетчиков и коректировки начислений. Начисления автоматом расчитываются на основание выше упомянутых таблиц и заносятся (при этом имеющиеся автоматические начисления в базе за этот месяц удаляются) в таблице начислений.

← →
ЮЮ © (2005-06-02 11:22) [9]

А зачем в области иметь внутреннюю кухню районов?
Они что, повторно все пересчитываю и проверяют?

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

← →
Carmen © (2005-06-02 13:35) [10]

Я склоняюсь к варианту обновления только сальда, суммы оплаты (общей)и суммы начисления (опять же общей)

← →
Yurij-7 (2005-06-02 14:49) [11]

За основу можно взять принцып обмена файлами между Центробанком и банками.

← →
Carmen © (2005-06-02 15:11) [12]

А по второму вопросу ничего????

← →
Sergey13 © (2005-06-02 15:23) [13]

2[12] Carmen © (02.06.05 15:11)
>А по второму вопросу ничего????
>Вопрос 2 (не по теме)Может еще кто-то пишет подобные программы, хотелось бы пообщаться.

Так ты уже с ними общаешься. Не заметил? 8-)

← →
Carmen © (2005-06-02 15:48) [14]

Может имеются форумы или сайты для АРМовцев.

← →
Sergey13 © (2005-06-02 15:52) [15]

2[14] Carmen © (02.06.05 15:48)
Дык ты уже на ём. 8-)
Ну на sql.ru сходи еще.

← →
cherrex © (2005-06-04 13:36) [16]

В свое время я эте проблему решил следуещим образом:
я создавал с помощью IBExpert таблицы и тригеры для ведения лога;
пом создавал базу (например отчет.gdb) и заносил туда данные из лог таблиц;
пересылал по TFTP отчет.gdb;
а на приемнике формировал SQL запросы основываясь на лог таблицы.

← →
Desdechado © (2005-06-05 20:16) [17]

рекомендую посмотреть в сторону укрупнения. варианты:
1. один сервер СУБД, один сервер приложений, много клиентов
2. один сервер СУБД, один терминальный сервер, много терминальных клиентских сессий
тогда никакого головняка с репликациями, единое место администрирования, легкость обновления структуры БД и рабочих мест

← →
Zacho © (2005-06-05 20:43) [18]

Desdechado © (05.06.05 20:16) [17]

Ага. И мегабаксы на выскоскоростные и надёжные линии связи :)

← →
Desdechado © (2005-06-05 22:40) [19]

вариант 1 не требует надежных линий связи, а вариант 2 - высокоскоростных (модем 33600 вполне пару сессий тянет)
это уж у кого что есть ;)

← →
Anatoly Podgoretsky © (2005-06-05 22:45) [20]

Оба вариант не требовательны к ресурсам.

← →
by © (2005-06-05 23:45) [21]

Desdechado © (05.06.05 20:16) [17]
посмотреть в сторону укрупнения
Этими вариантами мы перекладываем решение проблемы от программистов на пользователей.
Да, написать такое приложение легче. Но что делать если упал канал связи? Что делать если в головном офисе в здании отключили электричество? И все филиалы курят бамбук?
Так что тут компромис между тем кому легче жить - программисту во время написания ПО или пользователю - во время пользования ПО.

← →
Carmen © (2005-06-06 10:28) [22]

Все должно работать автоматом, юзер нажал на одну кнопку, комп набрал модемом номер, завязался с сервером, передал данные, разорвал соединение. Юзеру незачем знать что машина делает чтобы передать данные.

← →
Desdechado © (2005-06-06 11:15) [23]

2 by
вопрос философский
UPS поставить, резервный генератор в конце концов, ибо что это за сервер такой без них?
А в филиалах электричество не пропадает? Они лучше центрального офиса живут?
Каналы связи сейчас не часто падают. А упал - копайся в бумажках. Всегда есть, чем заняться помимо компьютерной обработки.

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

← →
by © (2005-06-06 11:40) [24]

Desdechado © (06.06.05 11:15) [23]
Да вопрос филосовский )
Я просто говорю исходя из опыта работы со стороны филиала. Какие-то проблемы - сидим, денег принять в кассу не можем. А клиентам то пофигу что у нас за проблемы, они сердятся.
А если в общем, то я считаю так - если не критично по времени работы, то можно и сервер приложений (или терминал, что даже лучше), а иначе - нужно подумать о каком то локальном буфере.

← →
Anatoly Podgoretsky © (2005-06-06 11:59) [25]

by © (06.06.05 11:40) [24]
Неправильно написаное приложение, не умеет работать в режиме портфеля.

← →
Amerika (2005-06-28 09:26) [26]

К вопросу 1:

Я так думаю, что в районах вообще не надо держать базу данных, она может оставаться в центре на серваке, доступ через расшаренный ODBC. Пусть переферия звонит по модему и получает доступ к БД, трафик мощный в таком случае не нужен. Если конечно телефонная связь не дорогая

← →
dolmat (2005-06-28 10:44) [27]

>Сейчас стала задача имея сервер в области получать данные из районов.
Для чего? Какой-то шишке необходимо знать сколько должен гражданин Х? И что из того? Получит нагоняй несколько раз директор а от него работник водоканала после чего работник начнет умышленно искажать данные. Зачем?

В принципе пишите лог, в конце дня пользователь его передает на сервер, сервер его обрабатывает. После чего формирует свой лог для клиента и отпрасляет его пользователю. Примерно таким образом работают банки используя для целей приема передачи текстовые файла и систему SFMail (Radius). Количество приемо-передач пока есть чего обрабатывать.

← →
Sergey13 © (2005-06-28 10:52) [28]

2[27] dolmat (28.06.05 10:44)
>>Сейчас стала задача имея сервер в области получать данные из районов.
>Для чего? Какой-то шишке необходимо знать сколько должен гражданин Х? И что из того? Получит нагоняй несколько раз директор а от него работник водоканала после чего работник начнет умышленно искажать данные. Зачем?

Правильно. Всякие сети и прочая централизванная обработка информации - это все фигня от лукавого.
"Это все придумал Черчиль в 18 году" (с)
8-)

← →
J55 (2005-06-29 16:23) [29]

Если сделать вывод, из всех советов то в данном случае есть следующие варианты:

1. Один центральный сервер в области и все работают с ним.

Плюсы: нет проблем с репликациями, централизованое администрирование, легкость обновления структуры БД, одна копия БД и АРМ-ов (можно проводить централизованое обновление АРМ-ов ;) и т.п.

Минусы: необходимы надежные каналы связи с хорошей пропускной способностью.

Переработка программы: минимизация трафика.

2. В каждом филиале и центральном офисе стоит одна копия программы и БД (везде структура одинакова). Данные реплицируются в центральный офис.

Плюсы: нет зависимости от каналов связи, одна копия программы и БД.

Минусы: необходимы разработать правила репликации и строго их придерживаться, будет много копий БД -> трудности обновления БД и поддержка одинаковых версий, в одни и теже АРМ-ы придется лепить функции необходимые для центрального офиса и филиалов.

Переработка программы: введение репликации -> скорее всего придется переписать программу, т.к репликация должна быть учтена уже в структуре БД.

3. В каждом филиале стоит версия для филиалов, в центральном офисе стоит версия для центрального офиса со своей структурой БД (далее ЦО).

Плюсы: нет зависимости от каналов связи, программа ЦО может разрабатываться отдельно или даже другим программистом, если в филиалах используются разные программы, то достаточно сделать для каждой экспорт в структуру ЦО и все.

Минусы: разные варианты программ и БД, следовательно все минусы с этим связанные.

Переработка программы: достаточно сделать экспорт :), зато придется писать версию для ЦО ;(.

PS: Все это конечно ИМХО и в зависимости от ситуации плюсы могут быть минусами и наоборот.
У нас сейчас тоже пока стоят перед подобной дилемой (в масштабе области). Но пока наверху стоят проблему придется решать на местном уровне (в масштабе района). Пока склоняюсь ко 2-му варианту.

To: carmen ©
Если интересно все это обсудить то пишите на мыло.

← →
Sergey13 © (2005-06-29 16:31) [30]

2 [29] J55 (29.06.05 16:23)
После беглого прочтения.
Минусы второго также присутствуют и в третьем варианте. ИМХО.

← →
Desdechado © (2005-06-29 19:33) [31]

2 J55
еще раз повторю - для случая терминального сервера НЕ нужны надежные каналы, НЕ нужны каналы с высокой пропускной способностью

оборванная сессия остается на сервере, к ней можно назад переподключиться, ничего не потеряв

Desdechado © (29.06.05 19:33) [31]
Может ему будет понятно по другому.
От того что удаленый компьютер отключился от терминальной сессии, терминал продолжает работать. Проверяется легко запускается что то долго играющее, затем отключение, спустя некоторое время подключение и видим, что работа продолжалась.
Да и куда ей деться, поскольку на удаленой стороне только монитор и клавиатура, а выключение монитора никогда не приводило к выключению компьтера. Текстовый вариант терминала называется Telnet. Я в свое время так любил качать файлы по ФТП на сервер, запускал закачку и отключался, чтобы не тратить деньги, а потом спустя некоторое время приходил обратно и уже заказывал закачку к себе на компьютер. Это когда каналы были маленькие, а компьютеры большие.

← →
J55 (2005-06-30 09:45) [33]

Desdechado
А что Вы понимаете под "надежностью каналов связи"???
И так ясно что при обрыве соединения ничего страшного с сервером не случится, только как пользователь работать будет, если ему данные вводить и получать надо, а связи полчаса нет????
Из вопроса автора темы видно, что речи идет о работе в том числе и с квитанциями абонентов в непосредственном с ними контакте и поэтому перерыв в работе даже на 5 мин. будет очень заметен.

Лично я под "надежными каналами связи" понимаю обеспечение соединения, которое не влияет на работоспособность приложения, в том числе и по времени рекции.

На счет пропускной способности способности спорить не буду, главное, что бы хватало. Кстати, какая нужна пропускная способность для одновременной работы 20 терминалов?

Приемлемая скорость получается уже при 33кб, рекомендуемая минимальная 64. Все что выше улучшает комфорт.
Понятия одновременная работа, на деле всего лишь мифическое понятие. Никакой одновременной работы как таковой нет, процессы передачи данных дискретны и разнесены по времени. На скорости уже в 128 кб сенасы передачи практически не будут накладываться друг на друга. Если посмотреть на типовую работу оператора, то скорость ввода редко превышает 200 знаков в минут и процесс это не непрерывный, а редкий. 10 буквочек набил и следующие 10 будут не скоро. Достаточно посмотреть на любую типовую работу с Вордом и особенно с Экселем в офисе.

2 J55
Надежность в классическом виде - это вероятность доставки сообщения получателю без искажений и в заданный промежуток времени.
Применительно к теме - это, на бытовом языке, сможет ли пользователь работать в своей терминальной сессии без потери данных и времени.
Так вот - сможет. А "получасовые пропадания связи" - это авария. Я очень сильно сомневаюсь, что такое имеет место, по крайней мере регулярно. С деревней Замухруевкой такое, может, и возможно, а вот облцентр-райцентр - не верю.
Но даже если такое случится раз в неделю, напишет на бумажке, потом занесет в БД, когда связь восстановится.

← →
J55 (2005-06-30 12:04) [36]

Desdechado
/Надежность в классическом виде - это вероятность доставки сообщения получателю без искажений и в заданный промежуток времени.
Применительно к теме - это, на бытовом языке, сможет ли пользователь работать в своей терминальной сессии без потери данных и времени./

Согласен.

/еще раз повторю - для случая терминального сервера НЕ нужны надежные каналы,/
А такое заявление, согласитесь, сбивает с толку. ;)

To All:
Если рассматривать варианты терминальной работы и стандартной клиент-серверной архитектуры с расположением сервера в центре, а АРМ-ов на переферии, то какие плюсы/минусы?

> А такое заявление, согласитесь, сбивает с толку. ;)
Уточню - НЕ ОБЯЗАТЕЛЬНЫ надежные каналы. Если они есть, то хорошо. Если нет, не смертельно.

> варианты терминальной работы и стандартной клиент-серверной архитектуры
в случае К-С одни минусы: сложность админ-я, обрывы связи с утратой данных и текущего состояния работы, огромный траффик, сложность обновления

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

Если имеется вариант со сбором информации с мест в центр, т.е. в филиалах только вводят данные, причем не повторяющиеся в других филиалах и при этом структура информации идентична, а в центре их лишь объединяют в одно целое для синтетики, причем сбор делается достаточно редко и не влияет на работу филиалов - это одно.

Если же информация филиалов может пересекаться, каждому филиалу постоянно нужны некие данные общего плана и причем в интеракивном режиме, сама информация в филиалах разная по составу и т.д. - это, простите, совсем другое.

В первом случае незачем тратиться на каналы связи, сервера и т.д., тем более, что далеко не всегда имеется даже возможность подключения ПК филиала к телефонной линии, не говоря уже об инете. Единственная проблема - справочники, решается достаточно простым способом, заключающемся в двух аспектах:
1. Существует "глобальный" справочник в Гл.офисе, который пополняется новыми сведениями из каждого очередного "пакета" каждого филиала по определенным алгоритмам.
2. Разработана жесткая система кодирования реквизитов справочника, которую операторы обязаны соблюдать, придерживаемая по возможности встроенным в программу блоком входного контроля.

Мне кажется, что у автора именно такая ситуация.

>>Все должно работать автоматом, юзер нажал на одну кнопку, комп набрал модемом номер, завязался с сервером, передал данные, разорвал соединение. Юзеру незачем знать что машина делает чтобы передать данные.

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

> в магазин за выпиской и закуской
только выписался, и тут же закусывать?!
ну, могём :))

← →
J55 (2005-07-01 17:13) [41]

carmen
Интересно узнать, к какому выбору Вы все-таки пришли?

Здесь не прозвучало.
Все вышесказанное хорошо для MS SQL или Oracl.
Для Interbase - сомневаюсь

[42]
слишком глобальное обобщение
в чем сомнения? чем они подкреплены?

← →
Qwerty666 (2005-08-01 15:25) [44]

Занимаюсь подобной фигней для теплосетей. СУБД: MAX DB (разновидность MySQL), язык - Java. СИнхронизация - по модему. Главная фишка РУЧНОЙ репликации - совсем необязательно иметь одинкаовые структуры таблиц в районах и в центральном офисе. А именно: в ц. офисе таблицы должны являться пригодными для использования ВЫБОРКАМИ, ВЫЖИМКАМИ из данных районов (ничего лишнего). Вариантов для однозначной идентификации записей в БД на ц. офисе (буду называть "сервером") - море (номер района+праймэри ки записи на районе+время добавления и т.п.). Но тут лучше придерживаться следующей тактики (работает с удалением): записи всех районов являются ПОДМНОЖЕСТВОМ записей на сервере. Удалять записи на сервере - только всем скопом. Гимор исчезает (и это правильный выход, вспомните, например, правила ведения журналов аудита ПБ). Если интересно - мыльте.

← →
Qwerty666 (2005-08-01 15:26) [45]

Синхронизация баз данных Найти похожие ветки