Не претендуя на оригинальность и предполагая, что всё изложенное ниже - велосипед, решил немного поделиться опытом по сабжу.

Вопросы синхронизации справочников (сопоставления элементов с максимальной аутентичностью) в нескольких базах возникают либо при обмене данными либо при работе по ОЛЕ (например с документами или теми же справочниками)

Способов синхронизации много, остановлюсь на самых распространённых
1. По коду
2. По наименованию
3. По комбинации "код+имя"
4. По IDD

Написав несколько обменников, пришёл к выводу, что эти способы не устраивают в общем случае. Почему - и так понятно.

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

Каждый элемент справочника, с известной долей достоверности, может быть опеределён через комбинацию реквизитов справочника. Это и есть "ключ".
Составной ключ формируется как "Реквизит1"+"Реквизит2"+...+РеквизитN
Количество реквизитов зависит от каждого конкретного случая (я ограничился пятью - вполне хватает). В качестве примеров:
1. "Ключом" справочника ТМЦ может служить комбинация "Штрихкод+Артикул+ЕдиницаИзмерения"
2. "Ключом" справочника "Клиенты" может служить комбинация "ИНН+ОКПО+РасчетныйСчет+Адрес"

и т.п.

Поле "ключа" может быть добавлено в реквизиты справочника, по нему установлена сортировка. Ключ можно формировать при записи элемента. Уже записанные элементы можно обработать обработкой. Можно и не "трогать" справочник (особенно если база удалённая) - ключ можно формировать динамически при переборе элементов.

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

В базе создаётся справочник "соответствия". У него всего два реквизита : "ключ другой базы" и "элемент текущей базы". При необходимости синхронизации справочников вначале происходит поиск по ключу в необходимом для этого справочнике. Если результатапоиск не дал - начинаем искать в справочнике "соответствия". Если и там ничего не нашли, задаём юзеру вопрос "Не обнаружен элемент такой то.Чего делать?". Три варианта ответа : "добавить", "пропустить" и "выставить соответствие". При первом варианте ответа элемент просто добавляется в справочник (конечно для этого нужно иметь все данные элемента из исходной базы - но это не вопрос). При втором варианте - всё понятно. При третьем - открывается список справочников конфигурации. Юзер выбирает вид справочника, а потом и элемент этого справочника, который соответствует искомому элементу. После подтверждения установки соответствия, в справочнике "соответствия" делается запись. При следующей загрузке данных (или обращении по ОЛЕ), программа найдёт в справочнике "соответствия" нужный ключ и получит элемент.

В чём приемущества данной схемы
1. в случае изменения реквизитов, не входящих в код (чаще всего юзеры любят играться наименованиями) ничего страшного не произойдёт
2. даже если изменили реквизиты, входящие в состав "ключа" - ничего страшного - можно выставитьсоответствие элементов
3. поменять соответствия легче лёгкого

недостатки
1.человеческий фактор при выборе реквизитов для формирования ключа и выставлении соответствия (бороться бессмысленно - нужен опыт работы)

Вот собственно и всё.

Хочу услышать замечания и просто мысли от прочитанного.

Дитер, пеши исчо, лучше на сайте типа дети.ру...

Fixin, ты?

(1) спасибо за замечание. Ничего если я здесь немного побуду? можно?

(3) Оставайся, меня не парит, мне просто смешно...

(4) пояснить сможешьиливсё на уровне подсознания?

Дитер, ты изобрёл не велосипед, ты изобрёл колесо.

(6)Дай пожалуйста сылку, где всё это написано

(3) Лажа. Абсолютная. Как пример могу привести случай семи тысяч новых элементов.
При необходимости синхронизации справочников вначале происходит поиск по ключу в необходимом для этого справочнике. Если результатапоиск не дал - начинаем искать в справочнике "соответствия". Если и там ничего не нашли, задаём юзеру вопрос "Не обнаружен элемент такой то.Чего делать?". Три варианта ответа : "добавить", "пропустить" и "выставить соответствие".
Как ты думаешь, сколько ты проживешь после встречи с юзером, который наслушался этих вопросов?

(7) http://www.msu.ru/info/struct/dep/vmc.html

(8) Пример из реальности

две базы по 20000-25000 элементов справочника "Номенклатура". Последняя синхронизация транрефом с год назад. Фирма торговая

После недели выставления соответствий уже в течении двух месяцев максимульное колдичество соответствий в день - одно-два. До 100 документов за одну выгрузку. Выгрузка два раза в сутки

(7) интересная статья  МГУ от ректора. Узнал много интересного о деятельности студентов. Чего дальше?

Дитер, тебе ссылку на колесо и велосипед тоже дать, чтобы ты убедился?

(+10) Кроме того, речь идёт о "динамической" синхронизации уже имеющихся элементов. Для новых элементов справочников - банальное добавление.

(12) Дай мне ссылку на описание синхронизации "по составному ключу" без вмешательства в структуру справочника и использование соответствий элементов

(14) Я такую лажу писал ещё когда только учился адинесить. Извини, но статью писать мне в голову не приходило...

(15)Слово "лажа" обоснуй. Где, в чём лажа?

(+16) И потом,счего ты взял что это статья? Я просто делюсь опытом. В своё время мне некому было подсказать решение. Не все может быть такие умные как ты.

(14) Ссылку дать не имею права, это очень секретная технология не для экспорта...

Вообще-то это уже 101-я тема Diter'а на форуме, а вот такое впечатление, как будто она - первая.

(18) Трёп?

(19) Вот блин. Да почему? Чтотакого я написал крамольного? Это всем известно?

Хорошо,ладно,это "лажа".

Кто какдобивается синхронизации справочников при обмене (запгрузке данных) или обращении по ОЛЕ к справочнику базы ОЛЕ

Последний раз я писал по заказу клиента через код связки.

(23) Что есть "код связки"?

Да просто реквизит числовой. Была синхра между бухой и торговлей. В бухе (или в торговле забыл уже) был на номенклатуре и контрагентах реквизит - код элемента из оле базы... Я это полтора года взад писал.

Что происходило при изменении элемента (например юзеры передумали и вместо "Вася" сделали "Петя",конечно по "Васе" движений небыло). Что было при вводе элементов в двух базах одновременно.

(+26) Работу с отдельным реквизитом "синхронизатором" я тоже прошёл давно. Не устраивает в общем случае

(26) Ничего не происходило. Были режимы обработки: "проверять реквизиты" или нет. Если по коду не находило и была включена проверка на реквизиты, то элемент синхрился. По крайне мере так просили. Я тогда ещё во франче гнил.
Ты вот лучше расскажи как мне в ТЗ четыре миллиона элементов загнать и чтобы винда не падала...

(28) Ещё раз. Разные элементыпод одним и тем же кодом связки. Выходитодин затирался в пользу другого? Чем отличается от поиска покоду? Не то...


Про тз -попили её на куски и работайс несколькими ТЗ. Для каждой свойучастокпамяти. А можновообщесдинамической ТЗ работать. Т.е. формировать тот участко ТЗ, который необходим вданный момент

Есть справочник типа лога, куда пишутся все изменения, которые происходят с объектами. Там обжайди, мдид и через 1с++ всё преобразуется.
Типа после свёртки базы там куча объектов, которые типа "не найден". Их надо удалить. Тупой способ - перебирать элементы и если "не найден" - удалять. Но ведь с каждым разом правильных элементов всё больше и больше. В ТЗ по прямому запросу не загнать - оперативки не хватает. В ТЗ - чтобы например первые полмилиона записей просто не проверять, т.к. они нормальные и нужные.

(29) А чем тебя синхронизация по коду не устраивает?
И вообще - как ты думаешь - для чего в справочниках код?

(29) Как это разные? Такого по идее быть не должно, а если есть, то это проблемы юзеров. Там и есть поиск по коду, тормоз. В реквизите код элемента ТОЙ базы.

Расскажи как ПолучитьРезультатыВ_ТЗ() сделать в разные таблицы.

(31) Чтобы элемент не записывался, если код не уникальный бугага :))

(31) Как будет работать синхронизация по коду присинхронном вводе элементов в двух базах сразу? Ты думаешь я не пробовал разные варианты?

(32) Такое будет 100 % при в воде элементов на двухбазах сразу. Ты меня торомозом назвал? Не слишком ли ты спешишь с выводами?

Дитер как всегда - жжет...

Нормальная схема. Но Дитер в своем репертуаре - как всегда, чуть-чуть не додумал... После нобольшой доделки схема будет нормально работать и будет универсальной.
P.S. примерно такая схема уже 4 года вертится и полет нормальный

P.S. в качестве примера можешь заглянуть в МОД...

(36) В моде синхронизацияидёт по коду мода. Я не прав?

Подскажи "додумку"?

(36) +1 К первому предложению. ПС: МОД - го.но..

(36) И вообще,кто нибудьможет внятно объяснить, вчём я ошибся (если ошибся).Схема эта рабочая. Работает на 5-6 предприятиях города, у которых стоят мои обменники.

Найди 5 различий между Фиксином и Дитером

(40) Короче понятно. Пи..здеть ты мастер. Поделу - ноль.

(41) Млять, на нахуя мне тебе, тормозу, объяснять устройство колеса и велосипеда?

Сам тормоз. Я тебе задал конкретный вопрос. Как отработает твоясхема вслучае, если на двух базах одновременно вносятся элементы справочника по сути своей разные. Исходя из твоих ответов понял - никак. "так не должно быть"... Ты сколько работаешь? Значит твоя схема с кодом связки ничем не отличается отбанальной синхронизации по коду. Лажа короче.

А про велосипед и колесо ты зря. Давай ссылку или извенись

(42) Ну можно было бы, конечно, из чувства сострадания к младшим братьям, да борзый он очень, однако...

Ну вот,ещё один с распухшим самомнением. Ну давай ты ещё расскажи какможносинхронизацию сделать. Или тоже "нет желания объяснять очивидные вещи....". Ещё один пи...дун короче....

(43) Дитер, код элемента писался в одной базе руками. Типа элемент с кодом в бухе 111 был в иторговле с кодом 222, но элемента с кодом 222 был реквизит, куда писался код 111 - соответствие. Чё те ещё не понятно? Если ты ввёл два в двух базах один и тот же элемент, то тебе в реквизит в торговле надо было написать код элемента в бухе. Всё работало и работает, наверное.
Про ссылку я тебе уже писал, тормоз.

(45) пи...дун тут конкретный есть, в (0). изобретатиль колёс и велосипедов, кулибин нии... цца

(47) Ивана Петровича Кулибина не трожь :--)

(46)
1. Базы за сто км. друг от друга.
2. В базе 100 штук товара,поназванию очень похожего, но по сути разного.....
3. руками (как ты говоришь) вбили два одинаковых кода связки вразные элементы....

Вотминимум три причины, по которым твоя схема лажа. Прощу уж тогдапросто тупо транрефом раз в неделю "сводить" справочники. Небось ещё и бабки за разработку этого получил?

(47) Полегче на поворотах.

(48) Не буду :-) Лана, всем пока, я бухать пошёл.

Ладно. на сегодня хватит. Если утонет - значит никому не надо. Прошу прощения за то,что отнял время.

Если у кого будут дельные(я подчёркиваю - "дельные") замечания или предложения-милости прошу из высказать. Только без навешивания ярлыков, с аргументацией.

Заранее спасибо

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

а мне пох... могут одновременно делать элементы в 5 базах...


P.S. опять Дитера заклевали...

Дитер, тебя наверно фдетцве в жопу отъибли, поэтому ты на все так бурно реагируешь. Главный обиженный на форуме. Изобрел колесо, ну гордись этим, теперь в холяндии есть колесо

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

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

Diter  - всё грамотно и хорошо. Спасибо тебе.
Но ты рассказал очевидные вещи.

На "небожителей" - старых пердунов, у которых потенции что-либо кодить давно нету (мозги ослаблены марихуаной) - не обращай внимания.
Они только могут вспоминать давно минувшие дни...

Сначала понты, типа (12).
Потом позор  - типа (25,28)...

(56) "ввод одного и того-же элемента в разных базах" - весьма спорное событие. Грубо говоря, можно только в одном случае утверждать, что это реально один и тот же элемент - если у физического объекта (который подразумевается под элементом) существует некий физический идентификатор (т.е. реальное свойство), позволяющий подтвердить его уникальность в рамках данной группы физических объектов. Лично мне известен только один такой случай - серийники мобильных телефонов. Во всех прочих - есть исключения.

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

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

Теперь про централизацию: покупатели разных филиалов - разные объекты - соответственно и разные элементы справочника. Если же (вдруг) один и тот же элемент может возникнуть везде и сразу - извините, так не бывает - где-то он будет первичен, а где-то - копия. Этот вопрос уже обсуждали. Мнения таковы:
а) допускать задвоения элементов, разгребать это уже потом
б) реализовать высокую скорость обмена данными между базами
в) централизовать контроль ввода за счёт связи ответственных лиц (например, по телефону менеджер звонит в центр и прашивает, а не приходил ли пять минут назад куда-нибудь покупатель Разгильдяев Обалдуй).

P.S. Живой пример из жизни: торговая сеть предоставляет кредиты. Пока покупатель не погасил один кредит - второй ему не выдаётся. Однако, хитрый покупатель может взять один кредит, и быстренько смотаться в другой филиал, где данных о нём ещё нет, и взять там ещё один кредит. Проблема задвоения элементов тут как бы есть, но она ничтожна по сравнению с проблемой самого факта такого случая. Что делать? Вариант а) тут неприменим. Остаётся вариант б) и, как дополнительная защита - вариант в). На практике же в) приходится применять куда чаще - просто потому, что ряд "клиентов" отсеивается на уровне СБ, даже не доходя до стадии попадания в справочник, а потом уже само СБ предупреждает филиалы, что "был тут у нас один, если к вам придёт - пните его хорошенько".
Сама же по себе потребность единого информационного поля в данном случае настолько актуальна, что в конце концов фирма приходит к факту необходимости объединения работы филиалов в одной базе за счёт дополнительных техсредств, что и происходит.

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

Браво! Я в восхищении! Все дело в организации работы,а не в технических ээээ...
ухищрениях што ли...
И даже более того, техническое решение предложенное в (0) это лишь
псевдо-решение этой проблемы,а сама проблема в принципе нерешаема,
в принципе!...
если конешно не существует иерархии компетенции,где каждый
"узел" занимается своим делом.

бред сивой лошади в ясную лунную ночь....

Во ёжик пурги нагнал!
По теории-то оно вроде и есть, а вот на практике как тиснуть столько запретов, это же куча мер с сомнительным результатом.

Пургу гнать - тоже уметь надо.
Я долго тренировался.

Чё к чему?
Написано: Рекомендовано в базу знаний: Ёжик в тумане - 06.08.2005 22:17
Не делал я этого.
Даже не собирался.

Туман у ёжикоффф
Это я записал, но ты не отопрешься

(нормальная БЗня, туповатая правда)

Всем зрасьте.

Ежёик ты не перепутал? Я про справочники говорил а не про документы. Параллельный ввод разных элементов - вещь реально существующая. Никакими префиксами это не разведёшь.

Теперь что касается товара с одинаковым ключом, который как ты говоришь. куплен в разных местах и по разному учитывается.. А ты не задумывался. что такой товар разваодится аналитикой? Если тебе пиво поставляют 20 поставщиков ты что. будешь заводить 20 элементов "пиво"?

Ещё раз - схема реально работающая. Несколько добавлений

В общем случае не обязательно запариваться с назначением "формулы" ключа. По умолчанию ключ формируется как комбинация "Код+Наименование".
На самом деле ключ состоит из двух частей - ключ элемента + ключ владельца. Естественно для элементов основных справочников ключ владельца пустой.

Никакими орг мерами не заставить операторов на торговых точках чётко придерживаться правил наименования элементов или их кодирования.

В общем так. Кому не интересно и он это знал ещё в младенчестве - бога ради не беспокойтесь и не напрягайтесь стуча по клаве буквы. Я этого не знал и дополз до этой схемы сам. Методом проб и ошибок. Сейчас обменник работает вообще без моего вмешательства. Юзеры стучат элементы как им вздумается. Для товаров - достаточно ткнуть сканером в штрих-код. для клиентов - переписать данные с одного счёта или накладной и т.п.


Я просил реальные мнения и реальные замечания..... Период "всё решается организационно" я уже прошёл. Не везде канает.... А это выход

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

А в такой ситуации твой метод провалится....

(71) Понятно. что до определённой степени это выход - потом стрелять надо....

Кстати. пит. надыбал ошибку в алсе по метаданным. Сюда дать?

(71) И ещё - опиши пожалуйста ситуацию. в которой составной код не даст адекватную синхронизацию справочников. Мне действительно интересно. Я не так давно на последнюю версию своего обменника перевёл всех своих клиентов (около 17 работающих точек). Откуда ждать подляну?

Ежик молодец. все четко разложил, а  из воинствующих которые,
то им можно только длину соплей посоветовать укоротить, а то запутались,
совсем запутались.
Да а теперь немного по теме:
как показали Малинецкий,Курдюмов и Капица,что любая динамическая система
F(T-t,....,....)=0 где t время отклика(актуализации) дин. системы на входное воздействие;
да так вот, чем больше время t,тем более хаотично ведет себя система и
это принципиально и доказано.
и обратите внимание система в уравнении однородная! А Ежик говорил о создании именно НЕ однородной системы. Молодчина.
Это ответ автору.

(73) а подляну жди тогда,когда время ввода у операторов несинхронизировано и
чем значимее величина невязки по времени,тем больше вероятность возникновения
коллизии.

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

(74) Где в умозаключениях ежика кроется ответ на мой вопрос? Кстати. какой вопрос? Я просил замечания и мнения. Никаких вопросов я не задавал.....

И ещё. ты щас с кем разговаривал?

(77) Много написал. Ниасилить...

(78) Щас - тебе простительно :))

(76) БэкАпы - это другое. Здесь речь о двух (во всяком случаи - не одной) базах. Обмен, доступ по ОЛЕ и т.п.

Ладно, завтра заскочу гляну. Может ещё кто чего скажет по теме. Меня интересуют не теоритические изыскания, а примеры из реальности. Кто, как, какие косяки? Пробовал ли кто делать так, как я. Какие результаты на каких объёмах. Короче - статистику.....

Опять дитеризм устроили?

(81) LOL!
"Меня интересуют не теоритические изыскания, а примеры из реальности"
Плакал...

Ошибку - давай. Сразу поправлю....

(70) "Параллельный ввод разных элементов - вещь реально существующая. Никакими префиксами это не разведёшь."
Префиксы разводят дубликацию кодов.
А дубликацию самих элементов вообще ничем не разведёшь, кроме головы вводящего. Это баян ещё с эпохи мезозоя. И странно, что ты это как-то легкомысленно воспринимаешь.

"Если тебе пиво поставляют 20 поставщиков ты что. будешь заводить 20 элементов "пиво"?"
Да, именно так. Потому что разная себестоимость и цены реализации тоже разные. Если этот товар считать одним, то у продавцов будут очень мыльные попы, когда один и тот же товар будет стоять на складе по 20-ти разным ценам, и его нужно будет умудриться не пересортить.

Вот тебе "пример из реальности": футболка была куплена на рынке. Штрихкода нет. Артикула тоже нет. Похожая футболка была куплена на другом рынке. И это - принципиально разные футболки, поскольку рынки находятся в разных странах. Производитель неизвестен, да он и не актуален - как правило, ставится страна, в которой был этот рынок. А вот сам рынок, где товар был куплен - очень актуален. Можно, конечно, добавить в ключ характеристику "рынок", то такая практика означает, что сей "ключ" просто впитывает в себя те характеристики, которые в данный момент актуальны для аналитики. А этот процесс бесконечен и не имеет универсальных решений.

Видел своими глазами попытку создания аналогичного "товарного ключа".
В него входили:
1) цена товара :)
2) код товарного подразделения
3) артикул
4) маленький кусочек наименования
Всё это работало, но с таким жутким скрипом, что лучше бы этого не было.

Туман у Ёжика....

Кстати, о птичках..

427
88 - 21.07.04 - 22:07
.....................
Насчет товаров... Да, не панацея... У одного из последних клиентов налетели - разные товары ОДНОГО производителя имеют одинаковый артикул... Зашибись...

в моей системе синхронизации одинаковый артикул - пох... Элементы будут различаться...

P.S. нельзя в основу синхронизации класть поля, которые может править юзер... НЕЛЬЗЯ!!!

P.S. если синхронизация односторонняя (например, доки едут из ТиС в Бух) - можно организовать отображение нескольких товаров ТиС в один в бух (но тут зарыто маленькое свинство)

если же товары ездят туда-обратно - отображение должно быть один в один...

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

"P.S. нельзя в основу синхронизации класть поля, которые может править юзер... НЕЛЬЗЯ!!!"
- вне всяких сомнений,
в противном случае это будет уже полное отсутствие синхронизации.

Давелось наблюдать одно "внедрение". Там внедренец сделал синхронизацию по коду+первым трём словам наименования. При этом наименование можно было свободно редактировать! Когда наименования отредактировали, да по нескольку раз, да не у одной тысячи элементов - вот тут началась такая жопа, что мало не показалось. И это жопа потом тянулась два года. Вот так.

GUID

Не читал всю ветку.
Вообще ИДИОТИЗМ.
Есть внутренний код ID он уникален. Он есть во всех базах...
Для случая синхронизации просто делаешь справочник - с двума полями с отбором и сортировкой - IDвПервойБазе, IDвоВторойБазе.

(90,91) я это Дитеру уже давно говорил... Но если до него не доходит...

Влом было читать все высказывания. Поэтому не знаю, дошел до середине, и не встретил ничего про это:
Про УРИБ кто-нибудь слышал вообще? Помоему все проблемы решаются, во всех справочниках, при любых изменениях данные синхронизируется.

(90) Пример из жизни

справочник в базе № 1 "Виды деятельности" - элемент под названием "основная" занесён под кодом "1" и имеет какой то внутренний код (например 200).
справочник  в базе № 2 "Виды деятельности" - элемент под названием "основная деятельность" занесён под кодом "5" и имеет какой то внутренний код (например 100).

Задача - при обмене данных загрузить (подставить при программном формировании документа) элемент "основная деятельность" (который фактически означает одно и то же что и "основная" в базе № 1) в базе № 2.

Ваше решение? GUID разные, коды справочника - тоже.Даже наименования разные.

Ну же господа профи....

427 - ошибка в описании работы с операциями.

ДлинаСуммыОперации - не катит
ДлинаСуммыОперация - катит. проверялось на 25 релизе 1С (dbf)

(+94) Для NS - про справочник соответствий - понятно. Не столь важно чего там будет соответствовать друг другу - внутренние коды или "составные ключи".

(0). Вопросы однозначной идентификации записи таблицы(кортежа)в реляционных БД расписаны довольно подробно и везде.

А вот если есть база данных  где есть сложности вобще понять кто Сидоров, а кто Иванов и сидит прогер и заливает туда екселевские таблицы и нет адекватного интерактивного ввода с элементарной проверкой на пустые поля ( прогер единтственной пользователь в базе, так сложилось :))  Эту базу уже ничто не спасет.

Всю ветку не читал.

Маленький вопрос к автору: чем не устраивает IDD?
Уникальный идентификатор, все по Кодду.
Или в теории баз данных уже появилось что-то новое?
Составной ключ-то ЗАЧЕМ?

Если для верификации, то вопрос поставлен абсолютно верно. Но это отдельная операция. Отсюда непонимание, а че написано в (0). (Сам сразу не понял).

Например, файл XML сначала проверяют, а потом уже юзают, так же и при обмене имхо делать, если есть такая возможность, нужно.

(97) Недостатки IDD
Предположим, в базе № 1 есть клиент "Иванов" с кодом 100, наименованием "Иванов" и IDD 100.
В базе № 2 есть клиент "ЧП Иванов" с кодом 200, наименованием "ЧП Иванов" и IDD 300. Как "свести" этих контрагентов.

Составной ключ, например состоящий из комбинации "ОКПО"+"расчётный счет". Позволит это сделать без выставления соответствия IDD.

Ещё вопрос. Удалили элемент справочника и тут же создали новый. Какой IDD будет у этого нового элемента? свободный? Следующий? Код удалённого элемента?

Как выставить соответствие IDD для справочника "ТМЦ", в котором 20000 элементов и в подчинённом ему справочнике ещё по 500? При условии, что весь этот товар, только с другими IDD находится в базе приёмнике. Совпадают некоторые "ключевые" реквизиты?

Идея с составным ключём в том и заключается, что данные в элементы ключа вносит юзер, беря их например с упаковки товара или накладной клиента. И не столь важно под каким именем занесли клиентов в базе № 1 и базе № 2. Совпадение комбинации ключевых реквизитов однозначно указывает на идентичность элементов

(98) >"В базе № 2 есть клиент "ЧП Иванов" с кодом 200, наименованием "ЧП Иванов" и IDD 300. Как "свести" этих контрагентов."

Отвечаю: имхо нужна предварительная фаза синхронизации справочников.
То есть имхо не нужно смешивать ее с собственно обменом.

А вот принудительно проверять перед выгрузкой, совпадают ли Код-Наименование-ИНН и пр. для указанных ИДД, и отваливаться при несовпадении с сообщением "Сначала выполните синхронизацию", я думаю, абсолютно правильно.

(98)
>>>В базе № 2 есть клиент "ЧП Иванов" с кодом 200, наименованием "ЧП Иванов" и IDD 300. Как "свести" этих контрагентов.

А зачем ?? По IDD - это "разные люди"

>>>Удалили элемент справочника и тут же создали новый. Какой IDD будет у этого нового элемента? свободный? Следующий? Код удалённого элемента?

Следующий

так про неё родимую (про синхронизацию) и идёт речь. Вот вы некоторые говорите - IDD. А я спрашиваю - как? Выставлять соответствия IDD? А если элементов справочника "Партии" больше миллиона? Да бог с ним - элементов справочника ТМЦ 20000 штук. По составному ключу - 90 ; совпадение. Остальные - сопоставляем. По IDD сопоставлять прийдётся все. Не сразу конечно, по мере поступления документов с этими элементами. Но всё равно - весь справочник

так про неё родимую (про синхронизацию) и идёт речь. Вот вы некоторые говорите - IDD. А я спрашиваю - как? Выставлять соответствия IDD? А если элементов справочника "Партии" больше миллиона? Да бог с ним - элементов справочника ТМЦ 20000 штук. По составному ключу - 90 % совпадение. Остальные - сопоставляем. По IDD сопоставлять прийдётся все. Не сразу конечно, по мере поступления документов с этими элементами. Но всё равно - весь справочник

(100) По сути это один и тот же клиент

(101) Блин, так бы и писал в (0), сразу все стало ясно.
Я правильно понял, что в (0) предлагается некая обработка, которая позволяет пользователю в визуальном режиме синхронизировать два справочника, чтобы у них сделать общие ИДД?

Как выставить соответствие IDD для справочника "ТМЦ", в котором 20000 элементов и в подчинённом ему справочнике ещё по 500? При условии, что весь этот товар, только с другими IDD находится в базе приёмнике. Совпадают некоторые "ключевые" реквизиты?

Так и говори пытаюсь синхронизировать 2 мусоросборника и непонятки по каким полям.

(103) Нет. В (0) Механизм синхронизации справочников по составному ключу и установкир соответствий элементов, для которых поиск по ключу ничего не дал.
(104) Причём тут мусоросборники? Речь о реальных справочниках, элементы которых присутствуют в документах, выгружаемых и загружаемых в разные базы.

(105) Автоматом ищет соответствие и молча его находит?
А если не находит? (например, ИНН совпадает, а фамилия - нет).
В этом случае обмен в 50% случаев дает ошибку, не так ли?

С точки зрения БД у тебя две  совершенно разные таблицы с разными записями. Первичные ключи то разные. И за тобой право как ты их собираешься синхронизировать. Хоть по высоте шрифта поля "наименование". И это все будет правильно и чисто субъективно.

(106) Если ключ состоит из комбинации "ИНН"+"Наименование" - предложение из трёх вариантов
1. Добавить элемент
2. Пропустить элемент
3. Выставить соответствие элементов

Выбираешь третий вариант и заносишь в справочник "соответствия" ключ элемента базы отправителя и элемент своей базы. При следующей загрузке автоматом подставляем соответствие.

Вообще пример очень не удачный. ИНН вещь сугубо уникальлная. Фамилдии не могут не совпадать.

(107) Как это "правильно"? Выше меня тормозом называли.....

(108) А как насчет сразу выкатить юзеру две колонки (слева одна база, справа - другая), и подсветить несовпадения?

Если есть хотя бы одно несовпадение по важным полям, блокировать обмен.

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

(110) а смысл? Не нашли код - юзеру три варианта....

Я сегодня для теста прогнал около 500 документов за одну выгрузку. Элементов справочника порядка 10000. Выставив "формулу" ключа. Добился того, что пришлось выставить только 10-15 соответствий. Остальное нашлось по ключу. Справочники в этих базах не синхронизировались никогда.

Какую картину ему видеть надо? У него выскакивает окошко.

"В ваше базе не обнаружен элемент "Вася Пупкин" справочника "Клинты". Его ключ - 1234567890%Организация%3216598. Чего делать будем?"

Дальше юзер открывает из этой же формы справочник "Клиенты" и находит, что у него есть "Пупкин Вася", которому просто забыли поставить ИНН. Юзер ставит соответствие и при следующей загшрузке у него автоматом подставляется "Пупкин Вася".

(112) Не знаю, у меня подсознательное чувство, что тут что-то не так.

Например, в одной базе "Вася Пупкин", в другой - "Пупкин Вася". В обеих не указаны ИНН. Что тогда?

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

(113)
А в этом случае они "найдутся" - ключ одинаков

%Организация%3216598

Дитеру - у тебя старый алс...
Эта ошибка давно исправлена - даже буква Я подчеркнута


Метаданные.ДлинаСуммыОперация
MetaData.OperSumLen
Синтаксис:
Метаданные.ДлинаСуммыОперациЯ
Назначение:
 Получить число - максимальное количество знаков суммы операции, включая разделитель целой и дробной части.
 Задается в пофигураторе при редактировании ОПЕРАЦИИ (нужно дважды топнуть на ОПЕРАЦИИ)

алс от мая этого года

(+1ё16) Я уже и копировал прямо из СП

алс от мая этого года? Да я уж вроде давно ничего не выкладывал...

Там и править то нечего, кроме опечпток

скопировано с боевой - в конфигураторе

P.S. - кидай пустышку нa karkarde(_)pisem.net - скину....

Теоретически "Ёжик в тумане" - безусловно прав!
Но "Diter"  - хочет решить проблему в частности! И его решение дает результат (допустим 99%): Юзеры рады - да! "Diter"   горд собой- да! Ну вылезет 1% - "смесь ёжа с колючей проволокой" - он юзера обвинит (и докажет), что не корректно задал поля ключей и опять будет прав. Юзеры теории не знают (как и большинство программеров) - нужен результат "малой кровью и на чужой территории".

(119) Я по моему с самого начала просил реальную ситуацию, в которой схема не сработает. Пока ничего кроме пустых слов не услышал. Ты не исключение.....

(120) получил. Отвечу через пару дней - я тебе подкину еще вордовский файлик с несколькими советиками...

(121) буду ждать...