Есть нетрафиальная задача, организовать постоянный обмен информации с тысячи информационных баз(самописных) с одной центральной, при этом условия обмена такого что вся первичка вводиться на тысячи баз в центральной возможны только изменения и дополнения к полученой информации ну и отчеты разумееться. Технические требования такого что жизненно необходимо(для центрального сервера) обмениваться только изменениями, для этих целей использую планы обмена и регистрацию изменений, все бы хорошо, за исключением того что при первом же тесте обнаружилась вот такое: в одной и в другой базе создали одно и тот же элемент скажем степень родства мать при загрузке в центральную элемент продублировался ну это и понятно так как внутренний код разный, если ограничить по наименованию то битые ссылочки появляються. И тут вопрос как организовать анализ одинаковых элементов по определенным реквизитам(Наименования, номер паспорта и т.д.) когда они создаються независимо друг от друга, имеються ли способы при формировании XML выгрузки сереализатором вместо ссылки проставить наименование и при загрузки искать по наименованию? Какие еще могут быть методы решения данной задачи? Обработку по выгрузки загрузке(типовую) не предлагать на клиентских ИБД сидять узбеки , распределенка не подходит, каждая клиентская база содержит только свою информацию, центральная всю. Как варианты решения вижу только: создать рег. сведений с уидами и объектами для сопоставлений, но это не надежно и криво со стороны быстродействия, второй вариант создать свой обменщик тоесть самостоятельно регистрировать изменения и ручками прописывать каждое поле для выгрузки и загрузки что долго геморойно и не айс.

никак

информация должна вводиться в одном месте и точка. А как ты это технически реализуешь - это уже нюансы

Млин. Вроде и по русски написано. Но читать невозможно.

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

Я собственно и спрашиваю об оптимальном техническом решении, не код программы(Упаси великий алгоритм), а лишь методология.

(0)
Управленческая проблема.
Решать только руководителям. Программное решение в любом случае выдаст фигню

Classic поясни. Фигню не выдаст если определения будут не ссылками а определенными реквизитами(коды, наименования и т.д.)но для этого что было без боли и слез необходимо это воткнуть на месте ссылки именно в механизме сериализации.

(7) вам надо написать правила обмена, в которых вы и зададите как искать и сопоставлять объекты.

у меня глаза вытекли :(

по сабжу - при коллизиях верхний узел прав.

или все данные в независимых РС и при обмене сливать наборы. Но это тормозит :(

(9) У него нет колизии, у него как раз обратная ситуация.

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

(4)
1. Вводятся в разных местах
2. Можно менять как хочешь. Как по твоему сделаны обмены между УТ и БП. Ведь это тоже разные конфиги

при загрузке в ЦУ проверять, есть ли оно такое, и, если есть - отправлять обратно удаление (+ ссылку на аналог). При загрузке в ПУ - смотреть удаления, если есть ссылка на аналог - то через поиск по ссылкам - заменяем в документах.

(13)+ можно даже при загрузке в ЦУ менять, а обратно отправлять измененные документы

(11) это из-за того, что глаза вытекли

ну и да, 1000 перифериек - это серьезно.

(7)
Ну вы знает как решать вопрос коллизий?
Ведь в одной базе могут завести сына Саша, в другую дочь Саша. Попадет только один ребенок. А как должно быть? Может ведь быть два ребенка.
В одной базе завели ребенка с одной датой рождения, в другой его же - с другой. Как потом разгребать будете, почему дата не та?
Та вообще куча нюансов возможна

(0) сначало я пытался внимательно всё прочитать не абращая внимания на твая ашибки и пропуски щнаков препинания, потом стал читать вдоль... потом - попёрёк... и потерял смысл вопроса.

Где для (0) аннотация?

(18)
Плюсто
(0)
Открой для себя абзацы

Classic. Коллизий не будет мне необходимо только избавиться от дублирования разрезов аналитики(категории) типа сестра брат мать отец, паспорт военник ИНН, пьянь нарик и т.д.

(16) 1С:Управление миром

(20)->(13)(14)

ну и вот еще запятых пачка: ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,

(18) Моя не знать руский моя знать одноэс

(21) да не. 1 нас около 100 перифериек - пришлось 1 промежуточный агрегирующий слой вводить, типа 1-10-100

(20) РС спасет тебя. Он сам за этим будет следить

(25) не совсем. при совпадении основного отбора  все, что не в основном отборе потрется при получении данных. оно не надо.

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

угу, у нас УПП и 16 узлов, обмены полные 2 раза в день уже тяжело, промежуточные центры необходимы при таком количестве. Топология не Звезда будет

Автора спасут облака) пусть эта тыща зверей сидит на одном серваке

(28) Промежутки то не проблема, проблема механизм обмена. Какой механизм для данной задачи оптимален будет?

Ветку топлю, т.к. подбная рууская языка тянет на правилу 5 - вандализма.

В каком случае в базе на все элементы уид может поменяться?

(30) правила обмена писать, где сопоставление элементов по наименованию и т.д. легче таки (29). Вводить в одном месте всё

(32) ни в каком, если специально не будете менять. Уид статичен

(31) Не знал что сайт патриотический

(34) Если базу выгрузить и загрузить уид не поменяется?

(35) надо меру знать. Опечатка - нормально, а постоянное коверканье - неприятно читать

(36) уид чего не поменяется? справочников, документов и т.д. - нет

Можно ссылочку по составу уида и алгоритму построения? Пожалуйста.

(39) это только в 1с скажут.

(38) Элементов БД справочники документы и т.д.

(41) норм всё, уид для того и нужен чтоб не менятся

Может ли помочь объект XTDO?

(43) нет, если не разбирать его руками

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

(45)+ и продолжать при загрузке менять по таблице.

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

В общем из всего этого можно заключить что: либо сопоставления по уидам при загрузке  по логике типа если по наименованию или другому реквизиту в ЦБД элемент есть то записать новый уид и связать с элементом для дальнейшей загрузки из этой точки либо  строить и парсить файл выгрузки ручками с разработкой формата, либо пнуть заказчика что бы все классификации были внесены в центральную а затем выгружены в клиенты

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

>>либо пнуть заказчика что бы все классификации были внесены в центральную а затем выгружены в клиенты
именно так. И новые заводить в центре. Не надо изобретать...

Насколько быстро сработает запрос по поиску элемента в рег. сведений в котором 10000000 записей?

(50) Надо футболиста найти

(52) нарисуй ему на бумажке что будет если воодить не в центре. Это не относится к 1с даже, просто логика

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

(54) почему не получится? база в интернет, веб-морда или тонкий клиент и пусть когда понадобится - вбивают, там контроль сделать легче. А дубли физлиц и контриков - это ад будет у вас, отчетность кривая

(55) Ты гений, веб клиент и не надо много баз данных. Ты злой гений мне надо перефигачить всю клиентскую часть.

(56) > (29). Не обязательно веб морда, тонкий клиент тоже в браузере работает