v7: Алгоритм синхронизации данных #653353

Здравствуйте. Прошу помочь в решении одной задачи, над которой бьюсь уже неделю. Заранее говорю, что не прошу писать код за меня, мне нужно только усвоить идею, алгоритм, может, кто-то уже делал подобное. Собственно задача: есть 3 семёрочных базы ТиС, структура идентична, через УРИБ не связаны. В них реализован механизм дисконтных карт (ДК), скидки по которым рассчитываются динамически в зависимости от суммы продаж. Информация о ДК хранится в соответствующем справочнике, суммы продаж накапливаются в регистре остатков при проведении Реализации. Необходимо производить синхронизацию сумм продаж по ДК между всеми тремя базами хотя бы раз в сутки. Обмены данными должны идти в автоматическом режиме и гарантировать, что не будет дважды загружен один и тот же пакет данных. Заранее спасибо за любые мысли по этому поводу.

МОД проще всего.

Из того, что я знаю о МОДе, он перероет всю конфу, а мне нужно синхронизировать только один из разделов торговли.

Через КД2 можно такое реализовать. Или КД1, что кому ближе. Но это надо осваивать, и долго.

хранить информацию в виде: ДК, ИБ, Дата (день продаж), Сумма.

а регистрацию изменений и квитирование тоже в кд сделаешь?)

Ну типа самому реализовать подобие механизма УРБД. Может быть и не очень сложно. 1. Обработка получает DBF с FTP 2. Догружает свой справочник ДК. 3. Выгружает в этот DBF свои новые записи. 4. Следующая машина отрабатывает аналогичный цикл и т.д. Естественно тема интересная, В DBF можно предусмотреть флаг закачен в БД1,БД2,БД3, Сделать назначеное задание, предесмотреть чисить это DBF, в случае закачки и т.д. и т.п. Хотя это все только в плане предложений. Может это и бред :-)

Я знаю КД2. Сам перенос я уже в ней написал. Проблема в автоматизации этого процесса. Если подробнее и на пальцах :), то, например, мы выгружаем из базы 1 продажи за период с 01.02 по 02.02. Выгрузили, запомнили где-нибудь этот период на всякий случай :). А в базу 2 выгрузка не дошла (инета не было). На следующий день какой период выгружать: с 02.02 по 03.02 или с 01.02 по 03.02?

ну а что тут может быть сложного? принципов всего два: 1)одна база должна быть ведущей. 2) каждый пакет должен иметь идентификатор

для этого база 1 должна получить ответ от базы 2

Это не бред )) "каждый пакет должен иметь идентификатор". Идентификатор чего?

надежный транспорт исключающий потрею при транспортировке

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

а базы случайно не в SQL и не на одном сервере? А то ж можно и вообще без обменов

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

зато у тебя будет регистрация изменений и перенос чего угодна, откуда угодна и куда угодно.

Не совсем то, что нужно. Базы SQL на одном центральном сервере. А как?

Тоже верно, но конфа и так переписана вдоль и поперек, идут всякие самописные обмены с 7-ми и 8-ми, и встраивать в нее еще и МОД - боязно как-то.

Квитирование - идея хорошая, сам думал использовать, тока как?!

брать движения напрямую из sql. например, через 1cpp

>>>>Базы SQL на одном центральном сервере 1. можно извратится и повесить тригеры 2. можно напрямую получать данные из всех трех баз в реальном времени 3. можно синхранизаровать средствами скуля 4. можно тупо через файл 5. можно при проведении доков писать сразу в три базы ну т.д.

точно так же, как делается в штатном УРБД

Хотелось бы некий вариант алгоритма, вроде "в пришедшем пакете проверить то-то, в ответе отправить то-то". Нельзя, т.к. из этих трех баз одна - "ведущая", в которой должны агрегироваться суммы продаж из 2-х других баз. А эти 2 базы - УРИБ-овские, обмены хоть и идут часто, но иногда инет в филиале пропадает надолго.

Как?

ведущей может быть вообще база "не из этих трех". и даже не на 1с :-)

в яндексе забанили?

Верно, но зачем плодить сущности? :)

Смотрю, смотрю...

зависит от задачи...

Кстати, интересная идея из : "ты можешь  забрать пакет за любой день (тогда тебе надо хранить пакеты и отправлять их по запросам". И на первый взгляд кажется проще, чем реализовывать квитирование.

в чем проблема? в данном случае нет ведущей (точнее не обязательна). в каждой базе доступна вся информация по ДК. Дублирования информации УРБД можно исключить.

а все варианты равнозначные

Уже делал что-то похожее?

Проблемы как минимум 3: 1) Как отследить изменение реализации задним числом? 2) За какой период делать выгрузку для каждой конкретной базы? Ведь для каждой "ведомой" базы выгрузка должна быть своя, если не по периоду, то уж по суммам продаж - точно. 3)Как бороться с возможным дублированием сумм в загружаемых данных?

я предлагаю вариант без выгрузки. Вам шашечки или ехать? Конечная цель какая? Определить сумму продаж по ДК. Так и определяйте ее на лету. три запроса к трем базам.

Вариант интересный. А как быть в удаленных филиалах, не имеющих доступа к нужным базам?

1 - При выгрузке выгружать новые и измененные с момента послелней выгрузки данные. Соответвенно в базах флаги "Выгружен" , "Изменен" 2 - За весь период но с условием "Выгружен" = 0, "Изменен"=1 3 - В случае загрузки Флаг в DBF "Загруженно". На мемент загрузки Загружать если "Загружено"=0;

:) так началось то все с и ответа на него Используйте МОД. А то смотрю все новые и новые пунктики в условиях появляются.

нет. просто считать умею...

к

Всем огромное спасибо за советы! Вы подсказали мне хорошую идею. Пошел развивать ее и писать код.

от же ж! мы ему идею, а он нам - куй! даже идею не обрисовал...

Не-не-не! Камрад, как можно! Обязательно отпишу, если из идеи что-то жизнеспособное получится. А пока - неохота позориться перед почтенной публикой :).

хы. дык может, обгадив идею сразу, мы тебе труд и время съэкономим? :-) а может, и посоветуем чего...

Ага! Сразу б вам обгадить! :)) Сейчас раб. день кончился. Завтра и напишу.

Всем привет. Если интересно, вот как я решил сделать. Итак, есть 3 отдельных базы ТиС (не УРИБ). Одна из них будет "центральной", в ней будут аккумулироваться продажи по дисконтным картам и рассылаться остальным двум базам. Во всех 3-х базах создаем справочник, в котором будем хранить дату последней выгрузки для каждой базы-получателя. Выгружать будем по принципу "кому надо - тот возьмет". Т.е. из каждой периферийной базы формируются файлы выгрузки и помещаются в каталоги на FTP-сервере. Затем центральная база загружает ВСЕ файлы, которые найдет в этих каталогах (файлы после загрузки удаляются), сама формирует файлы выгрузки и кладёт в свой каталог на FTP. Периферийные базы загружают предназначенные для них файлы. Цикл обмена закончен. Если данные меняются задним числом, то дата последней выгрузки откатывается на это число, и след. обмен выгрузит новые продажи. Что получаем в итоге: выгрузки/загрузки идут синхронно, не нужно реализовывать квитирование, обмены не чувствительны к разрывам связи с центральным офисом и даже с FTP-сервером (т.к. просто в следующий раз к уже выгруженным добавятся новые файлы). Если по какой-то причине одна из баз не "заберет" свои файлы, то ничего страшного не случится, т.к. это можно будет сделать при следующем обмене (т.к. файлы выгрузок остаются на FTP).

Делал подобную синхронизацию через 8-ку. 1. Сделал простую конфу на 8, нужные справочники и план обмена. В плане обмена заводишь для каждой базы 7.7 узел. 2. Повесил регламент. Конектимся по COM поочередно к базам на 7.7, забираем изменения и регистрируем изменения для остальных узлов. 3. Потом выгрузка изменений для каждой базы 7.7.

Что-то не понял - при чем здесь 8-ка, если базы все 7-ные. "...Конектимся по COM поочередно к базам на 7.7..." - не подходит, т.к. базы на территориально удаленных серверах.

Так удобно, если все базы в локалке.