Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Синхронизация баз
|
|||
|---|---|---|---|
|
#18+
Обращаюсь за помощью к форумчанам, как к последней инстанции ибо сам ничего толкового придумать не смог. Опишу в кратце проблему. Имеется база с кучей таблиц и общим количеством записей около 100000. Эта база записана в 8 подразделений и головное управление. В базу вносятся новые записи, удаляются и корректируются во всех подразделениях и в управлении. Стоит вопрос, как получить измененные данные из подразделений и внести их в базу управления, и соответственно, из базы управления изменения перенести в базы подразделений. Подразделения имеют довольно посредственную связь с управлением - модемы, причем скорость чаще всего 9600, линию по долгу занимать нельзя. С базами в данный момент приложение foxpro работает на прямую. Стоит ли в данном случае городить клиент-сервер? Подскажите в какую сторону копать. Буду благодарен за любую помощь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2005, 09:25 |
|
||
|
Синхронизация баз
|
|||
|---|---|---|---|
|
#18+
Посмотрите поиск на данном форуме - мы уже подробно обсуждали эту тему здесь. Ключевые слова: "репликация" или "replication" Удачи! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2005, 09:28 |
|
||
|
Синхронизация баз
|
|||
|---|---|---|---|
|
#18+
Это одна из самых тяжелых тем с которой я работаю. Она возникает на этапе разрастания предприятия. Сначала один филиал, затем много. Для начальника по барабану как ты это сделаешь, ему кажется что это легко. В форуме тебя направят к "гениальным" технологиям будущего из учебников. Не ходи туда, слушай сюда: 1) Все без исключения списки должны иметь уникальный код. 2) счетчик кодов по каждому из справочников в каждом из филиалов должен иметь свой интервал. например: Фунюково 0-10000 Коровино 10001-20000 Горелово 20001-30000 Петров 123 557 124 Теперь самое главное: При пересылке данных все списки перекодируются с помощью таблицы соответствия кодов. Её структура (в моем случае такова): ID * ID_LIST - идентификатор списка 1 DOM - идентификатор филиала 1 KOD - код записи 557 KOD_MAIN - код записи в офисе 123 DATE_REFRESH - дата обновления {} таблица соответствия в каждом филиале (удаленном месте) своя и обновляется при получении данных. Записи которых нет в таблице соответствия добавляются и заносятся в таблицу. Может быть это выглядит как выпиливание паровоза лобзиком, но я тоже ломал голову достаточно долго, ничего иного не придумал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2005, 11:04 |
|
||
|
Синхронизация баз
|
|||
|---|---|---|---|
|
#18+
Плюс по возможности централизовать ведение справочников. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2005, 12:23 |
|
||
|
Синхронизация баз
|
|||
|---|---|---|---|
|
#18+
Hi DMITRY_PEREDISTY! Хех, а править значится никто ничего не правит, тока новые вносит :) И про конфликты совместного доступа (когда в разных филиалах поправили одну и ту-же запись) ты предпочитаешь забыть, и про "пропущенные" сеансы репликации (ну непогода была, не работала связь 2 недели!), про "дублированные" репликации (не знал и ещё раз то-же самое сбросил) и про прочие прелести... Posted via ActualForum NNTP Server 1.1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.01.2005, 01:22 |
|
||
|
Синхронизация баз
|
|||
|---|---|---|---|
|
#18+
Igor Korolyov Так вы за репликацию или против? Или вы против варианта предложенного DMITRY_PEREDISTY? В идеале одна и таже запись может меняться только в упарвлении и в филиале. Хотя как получится на самом деле можно предположить... Для того чтобы запустить репликацию на базе mssql мне придется установить sql сервера на всех филиалах, если я правильно понял. В некоторых филиалах всего по 2 компьютера с 64 мб и то под управлением win98, боюсь sql туда не встанет. Хотя если другого выхода не будет, наверное придется апгрейдить машины. И еще один вопрос меня интересует, сколько времени займет репликация на канале 9.6кбит, если за 1 день было отредактировано и добавлено скажем 100 записей? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.01.2005, 09:31 |
|
||
|
Синхронизация баз
|
|||
|---|---|---|---|
|
#18+
Сначала нужно ответить на следующие вопросы: 1. Есть ли общие справочники (например, номенклатура товаров) и кто их ведет. 2. Нужно ли, чтобы информация из одного филиала попадала в другой, или только из филиалов в центр. 3. Будут ли в центре редактировать данные из филиалов. Если будут, то чья правка должна остаться, если одну и ту же запись отредактировали в двух местах. 4. Каков полный объем данных, и какое количество изменений за день. 5. Как часто нужно синхронизировать данные - несколько раз в день или раз в неделю. Репликацию на Фоксе можно сделать в самом простом случае - если справочники ведутся в центре, данные перемещаются только в одну сторону, и для синхронизации можно пересылать базу целиком. Так, кстати, работает синхронизация в 1С с внешними приложениями через файлы. Если ситуация сложнее, то нужно смотреть по месту, можно ли обойтись малой кровью, или придется менять платформу. К слову, у меня был положительный опыт синхронизации баз не на MS SQL, а на Sybase ASA. Там очень низкие системные требования, и хорошая система репликации. Обновления передаются в обе стороны, через файлы или E-mail. Самый большой минус - слабая поддержка продуктов Sybase. Литературы - ноль, и спросить практически не у кого. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.01.2005, 12:06 |
|
||
|
Синхронизация баз
|
|||
|---|---|---|---|
|
#18+
Hi dmitryx! > Так вы за репликацию или против? Что значит за или против? Странный вопрос... Ты вот за то чтобы солнце вставало на востоке или против? Она есть, и её надо использовать. Возможно ты не совсем понимаешь что это такое - ну так поищи материала, почитай... И ещё - вовсе не связана она с MS SQL или любым другим сервером. Это просто технология согласования ряда разделённых источников информации - на фоксе такое вполне реально реализуется - главное знать ЧТО реализовывать. > Или вы против варианта предложенного DMITRY_PEREDISTY? Я против шапкозакидательства - "Репликация? Да раз плюнуть!" Конечно есть такие схемы, когда можно всё сделать за пол-часа 20 строками кода, но советовать такое всем я бы не стал - надо сначала поставить задачу (строго, формально, определить протоколы - кто, что, как часто, каким образом и т.п. - в общем массу вопросов прояснить) и лишь потом её решать. Выбрав для этого наиболее подходящий способ. Да что я в самом деле прописные истины говорю :( > В идеале одна и таже запись может меняться только в упарвлении и в > филиале. Хотя как получится на самом деле можно предположить... Так определись сначала! Пересекаются филиалы по данным или нет, нужно отслеживать конфликты или нет, каков объём ввода/исправления - чтобы понять нужно использовать инкрементные схемы репликации (т.е. отслеживать только "изменения" и их пересылать), или "полные" (там кстати тоже есть масса вариантов позволяющих минимизировать траффик)... > Для того чтобы запустить репликацию на базе mssql мне придется > установить sql сервера на всех филиалах, если я правильно понял. Да. Причём встроенные механизмы по моим сведениям для таких каналов связи совершенно не годятся... А рисовать свои собственные - весьма накладно, да и толку от того чуть - тогда уже проще то-же саоме на фоксовых базах соорудать. > В некоторых филиалах всего по 2 компьютера с 64 мб и то под управлением > win98, боюсь sql туда не встанет AFAIK есть версии что встанут и туда. Другой вопрос смогут ли они обеспечить требуемый уровень сервиса, и не убьют ли тебя юзера, привыкшие к высочайшей скорости файл-серверных приложений... Да и вообще без перепроектирования тогда не обойтись - это точно. > И еще один вопрос меня интересует, сколько времени займет репликация > на канале 9.6кбит, если за 1 день было отредактировано и добавлено скажем > 100 записей? Если канал "идеальный" (т.е. без сбоев и ошибок даёт стабильные 9600), и если принять за размер записи скажем 200 байт (итого 20Кб полезной информации), накинем для служебной информации ещё 20 Кб - получим что-то типа 35 секунд :) Хотя реально надо бы дождаться от принимающей системы подтверждения - а значит надо учесть время на обработку этой инфы там, ну и передача "обратно" - от центра к филиалам исправлений - т.е. пару минут IMHO ближе к истине... Posted via ActualForum NNTP Server 1.1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2005, 04:24 |
|
||
|
Синхронизация баз
|
|||
|---|---|---|---|
|
#18+
Hi karly™, Igor Korolyov > 1. Есть ли общие справочники (например, номенклатура товаров) и кто их ведет. Да, общие справочники есть. Информация вносится как в управлении, так и в филиалах. > 2. Нужно ли, чтобы информация из одного филиала попадала в другой, или только из филиалов в центр. Только из филиалов в центр и обратно. Движения данных между филиалами нет. > 3. Будут ли в центре редактировать данные из филиалов. Если будут, то чья правка должна остаться, если одну и ту же запись отредактировали в двух местах. Правка в центре имеет приоритет, но желательно при возникновении конфликтов иметь возможность их разрулить и руками. > 4. Каков полный объем данных, и какое количество изменений за день. Вся база 85мб. За день может быть отредактировано/добавлено 100-150 записей (хотя скорее всего меньше), в килобайтах это примерно 40-60кб. > 5. Как часто нужно синхронизировать данные - несколько раз в день или раз в неделю. Достаточно 1 раз в день. Igor Korolyov, согласен знаний по репликации пока у меня маловато. Читаю статьи, форумы, набираюсь ума. Вот уже вторую неделю я пытаюсь придумать, как мне решить эту проблему. После разговора с начальником от идеи реализовать репликацию на mssql пришлось отказаться, придется делать на фоксовых базах. У меня была мысль использовать триггеры для отслеживания изменений, но поскольку до этого я с ними не имел дела, то с первого раза ее реализвать не получилось, в прочем со второго тоже. Просто не знаю с чего начать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2005, 12:33 |
|
||
|
Синхронизация баз
|
|||
|---|---|---|---|
|
#18+
А чем вызван отказ начальства перводить на MS SQL? Дело в том, что 80, если не 90% проблем на нём уже решено? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2005, 12:41 |
|
||
|
Синхронизация баз
|
|||
|---|---|---|---|
|
#18+
Как реализовать фиксирование изменений с помощью триггеров, можно посмотреть здесь В принципе, этот пример несложно переделать, чтобы вместо текста создавался лог sql-команд insert, update, delete. И пересылать лог за какой-то период. Если справочники ведутся и в центре, и в филиалах, то возникают проблемы ввода одинаковых строк в разных местах, и синхронизации справочников между филиалами. Можно реально добавлять строки в справочник только после ручной проверки и подтверждения в центре, а после этого синхронизировать со всеми филиалами. Правки данных филиалов в центре возникают чаще всего из-за организационного бардака. И решается эта пробема чисто организационно, запрещением правок в центре :-) В противном случае, придется передавать данные не только из филиалов в центр, но и обратно, а это существенно усложняет процесс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2005, 14:25 |
|
||
|
Синхронизация баз
|
|||
|---|---|---|---|
|
#18+
Hi A Chuveljov! Извиняюсь у остальных многоуважаемых господ за оффтопик :( А не будет ли многоуважаемый Дон столь любезен, чтобы поделится со мной технологией, позволяющей проводить репликацию между множеством MS SQL серверов, соединённых ненадёжными и медленными каналами связи? Такими, что единственно более-менее работающее решение по передаче информации между узлами - это использование электронной почты. У нас вот уже с пару месяцев целая группа корпеет над реализацией подобной схемы (именно на MS SQL), и что-то НИЧЕГО стандартного они использовать не могут (по причине кривости, медлительности или крайней ограниченности имеющихся средств) - всё приходится руками писать - от собственно триггеров, служебных таблиц, до XML-парсеров... Posted via ActualForum NNTP Server 1.1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.01.2005, 23:59 |
|
||
|
Синхронизация баз
|
|||
|---|---|---|---|
|
#18+
Нашел, что я тут на форуме писал про один мой проект: Я делаю следующим образом - на W2k сервере крутится web service - который служит для приема данных в буфер. Буфер - контйнер базы данных VFP 8.0 - то есть в нем реализован механизм транзакций и если все принятые записи после завершения транзакций грубо говоря записались то посылается ответ .t. на удаленный клиент, который ждет ответа 5 минут. На W2k крутится еще Daemon - он через регулярные промежутки времени смотрит буфер и переаисывает его в актуальную базу данных... На клиенте стоит Daemon который через определенные промежутки времени соединяется с удаленным сервером и передает туда все записи у которых пустое поле время последней передачи - при получени положительного ответа от web services - это время проставляется в это поле - нет разрыв и повтор передачи... Везде где можно транзакции, блокировки и уникальные индексы каджой записи на основе кода филиала и sys(2015)... Примерно так. Просто и надежно как автомат Калашникова... Все ограничено только вашей фантазией - все остальное уже есть в VFP 8.0. Хочу добавть, что все это работает через наши не очень хорошие модемные линии - но идея такова - что все филиалы и головная контора смотрит в интернет, то есть Вы не отвечаете за связь (кто плавал - тот меня понял о чем я ) ... Good luck! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.01.2005, 12:58 |
|
||
|
Синхронизация баз
|
|||
|---|---|---|---|
|
#18+
karly™, спасибо за пример, очень интресно. Сам хотел реализовать нечто подобное, но мозгов не хватило. Сейчас буду ковырять. В общем и целом проблема именно организационная, но от меня тут мало что зависит. Приходится делать то, что скажут. A. Chuveljov Отказ вызван большой трудоемкостью процесса. Технология не изученная, и изучать типа некогда... Sergey Ch Спасибо, тоже интересная технология. Но можно ли тут обойтись одним FoxPro, или надо будет еще C# ковырять или еще что, чтобы web services писать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2005, 16:49 |
|
||
|
Синхронизация баз
|
|||
|---|---|---|---|
|
#18+
dmitryxSergey Ch Спасибо, тоже интересная технология. Но можно ли тут обойтись одним FoxPro, или надо будет еще C# ковырять или еще что, чтобы web services писать? Только FoxPro (то есть там прямо на диске есть SOAP 3.0 ) и он интегрирован в VFP 8.0 (7.0) - Web Service строится и регистрируется путем нажатия пары кнопок... Все это работает уже более трех лет... Good luck! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2005, 17:21 |
|
||
|
Синхронизация баз
|
|||
|---|---|---|---|
|
#18+
Hi Sergey! Идея с e-mail как транспортом для пакетов репликации IMHO ещё более проста и надёжна (вместо WebService делается сканер некоего "служебного" e-mail ящика, собирающий оттуда пакеты и обрабатывающий). Ибо есть ещё места, где Inet в большом ... не_будем_это_называть, зато корпоративная почта ходит прилично :) Posted via ActualForum NNTP Server 1.1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2005, 02:49 |
|
||
|
Синхронизация баз
|
|||
|---|---|---|---|
|
#18+
Все это время разбирался с триггерами, SOAP, веб сервисами и сопутствующими задачами. В результате возникло несколько вопросов, в частности по веб сервисам... Sergey Ch В принципе, как получать данные с сервера я понял, тестовые примеры работают, NorthWind расковырял - тоже более-менее понятно, но как мне передать курсор от клиента на сервер пока что-то не доходит. Так же не совсем ясно, как контролировать целостность переданных данных. Я должен быть уверен, что запись целиком передалась. А что будет, если передача оборвалась, скажем, на середине? Можно ли здесь применить механизм транзакций или есть какой-либо другой способ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2005, 19:10 |
|
||
|
Синхронизация баз
|
|||
|---|---|---|---|
|
#18+
но как мне передать курсор от клиента на сервер пока что-то не доходит. - пока делайте так - в web service есть процедура, которая принимает параметр - вот этот параметр и будет Ваш курсор... ну не совсем курсор а XML файл (то есть на клиенте из курсора далаете XML строку и ее передаете на WS - а там снова преобразуете из XML в курсор - все работает очень быстро), но есть ньюансы - надо править реестр, чтобы передавать за раз более 36 Kb Так же не совсем ясно, как контролировать целостность переданных данных. - это целое искусство, но ничего сложного - в базе на клиенте специальное поле - время передачи на сервер - буферизация таблицы - курсор ушел на сервер, там специальная транзакционная таблица с буферизаций 5 тоже - если при завершении транзакции со сбросом буфера прошла удачно - ответ на клиент +1 - нет -1 откат буферизации и передача снова... Работает как часы - причем на сервере ставите демон, который и пердает автоматом и принимает данные через указанные Вами промежутки времени... Далее на сервере процедура на WS которая аналогично разносит уже с блокировкой и буферизацией 3 каждую принятую запись - рухнул сервер, следующий раз все продолжается снова со следующей записи... Я должен быть уверен, что запись целиком передалась. - см. выше А что будет, если передача оборвалась, скажем, на середине? - передваться будет снова с начала - принцип тут тупой с нашей связью - все или ничего... Я еще дроблю пакеты на передачй по 10 kb - так лучше, быстрее, надежнее... Можно ли здесь применить механизм транзакций или есть какой-либо другой способ? - только как я рассказал и транзакции и буферизацию и TRY CATCH... Но у меня была еще дополнительная проблема - данные идут от VFP 8.0 к FPD 2.6... Good luck! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2005, 23:22 |
|
||
|
Синхронизация баз
|
|||
|---|---|---|---|
|
#18+
ЧуднЫ крестьянские дети!.. Я правильно понял: вас не устраивает скорость непосредственного соединения, поэтому вы решаетесь на соединение через третье лицо? P.S. Сейчас я произведу трель модема, а вы услышите её в сети. Все в сеть! В сеть! (по мотивам произведения Дж.К.Джерома) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2005, 23:36 |
|
||
|
Синхронизация баз
|
|||
|---|---|---|---|
|
#18+
bobitЧуднЫ крестьянские дети!.. Я правильно понял: вас не устраивает скорость непосредственного соединения, поэтому вы решаетесь на соединение через третье лицо? Простите, а в чем Ваша проблема? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2005, 23:42 |
|
||
|
Синхронизация баз
|
|||
|---|---|---|---|
|
#18+
Да, как у многих - знаний не хватает. И опыта тоже мало. Такая же и у меня проблема, как выше описано. Вот и читаю себе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2005, 23:54 |
|
||
|
Синхронизация баз
|
|||
|---|---|---|---|
|
#18+
Hi dmitryx! Поковыряй ещё - там как раз пример рассчитан на передачу ИЗМЕНЕНИЙ (апдейтаграммы) которые и приведут курсор на стороне Web-сервиса к виду, идентичному тому что есть на клиенте. А т.к. Web-сервис уже непосредственно с СУБД связан, то можно через TableUpdate() (подкреплённый CursorAdapter-ом) сброс изменений сделать. SOAP сам контролирует "целостность" канала связи - если твои данные (апдейтаграмма или просто строки с новыми значениями) не дошли целиком до Web-сервиса, то и его метод не сработает... Posted via ActualForum NNTP Server 1.1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.03.2005, 02:28 |
|
||
|
Синхронизация баз
|
|||
|---|---|---|---|
|
#18+
bobitДа, как у многих - знаний не хватает. И опыта тоже мало. Такая же и у меня проблема, как выше описано. Вот и читаю себе. Понятно... У меня сейчас другая проблема - часть таблиц нового проекта будет хранится в дополнении и на локальных машинах - разрабатываю синхронизацию и для этого случая В принципе ничего сложного - записи физически не удалять а ставить признак + время последнего измения (индекс по этому полю и передача последней даты в качестве параметра на WS) - и возврат на клиент только измененной информации... Ну а WS в нашем случае почти классический вариант business-services tier ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.03.2005, 09:44 |
|
||
|
Синхронизация баз
|
|||
|---|---|---|---|
|
#18+
Hi Sergey! разрабатываю синхронизацию и для этого случая В принципе ничего сложного Это лишь первое впечатление :) Когда задача обрастает подробностями становится жутковато - триггера, RI, транзакции, конфликты изменений - всё это должна учитывать репликация - и это вовсе не тривиальная задача :( Posted via ActualForum NNTP Server 1.1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.03.2005, 18:09 |
|
||
|
Синхронизация баз
|
|||
|---|---|---|---|
|
#18+
Sergey Ch, Igor Korolyov большое спасибо за помощь - передача данных заработала в обе стороны :) Но всплыла еще одна проблема, не знаю даже как я раньше не заметил... Для записи изменений я использовал решение , ссылку на которое давал karly™. А проблема в том, что в нем не обрабатывается коммадна INSERT INTO. Вообще то она обрабатывается, но не совсем правильно - как APPEND BLANK, т.е. создание новой записи фиксируется, а данные пропадают... Все мои эскперименты к успеху не привели, может кто подскажет как побороть? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2005, 10:58 |
|
||
|
|
start [/forum/topic.php?fid=41&tid=1594686]: |
0ms |
get settings: |
8ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
49ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
43ms |
get tp. blocked users: |
1ms |
| others: | 242ms |
| total: | 370ms |
| 0 / 0 |
