Здравствуйте

Подскажите пжта как описать проверку на наличие указанных данных на другом сервере?

Описание:
При получении из другого сервера№2 данных о компании, система должна до записи данных в БД, осуществить проверку на наличии указанной компании в БД сервера №1.
Предлагаемый алгоритм:
1. Проверка по наименованию вышестоящего объекта, при совпадении переход  к п.2 поиску по наименованию компании. Если совпадении нет, система сообщает об этом пользователю
2. Проверка по наименованию компании, при совпадении, осуществляется обновление данных. Если совпадений нет, система создает новый объект в подчинении вышестоящего объекта.

Пример:

На сервере №2
1.ООО "Маяк"
 1.1. ООО "Филиал 1 маяка"
 1.2. ООО "Филиал 2 маяка"

На сервере №1
1. ООО "Маяк"

Пришли данные о ООО "Филиал 2 маяка" из сервака №2 на сервак №1
Система проверяет на наличии в БД сервака №1 объекта с наименованием ООО Маяк.
Если находит, то дальше проверяет на наличие в БД, в структуре ООО "Маяк" объекта ООО "Филиал 2 маяка"

1. Сверка по названию - плохая практика. Только по уникальному коду.

2. У вас м.б. только два уровня вложенности? Перекачка данных только односторонняя?

3. Вышестоящий объект нужно как-то назвать, а то не звучит... Вначале дать определение:
* Группа компаний (ГК) - объект на первом уровне в сущности такой-то
* Компания - объект на втором уровне в сущности такой-то

4. Ну описать примерно так и надо, только как-то коряво звучит, я бы написал так:
При получении с сервера№2 данных о компании, система должна до записи данных в БД осуществить проверку на наличии указанной компании в БД сервера №1 по следующему алгоритму:
1. Проверить по коду КГ, при совпадении перейти к п.2. Если совпадении нет, система должна сообщить об этом пользователю (кстати как? Перекачка данных идет в фоне?)
2. Проверить по коду компании, при совпадении система должна обновить данные по Компании. Если совпадений нет, то система должна создать новый объект Компания в подчинении его ГК.

5. Можно такой алгоритм выделить в отдельное описание и на него ссылаться при перекачке и других сущностей.

Спасибо большое за ответ!

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

2. Перекачка данных двухсторонняя.

3.Уровень вложенности может быть и больше. Это конечно же осложняет проверку.

4. Да я так и сделал, выделил в отдельный раздел. Так действительно удобнее.

5. Порекомендуйте пжта, а как определить по какому атрибуту стоит производить сначала проверку?
Т.к. компании есть следующие атрибуты:
Наименование (текст): Филиал №1
Организационня форма (текст): ООО
Расположение (классификатор стран): Россия
Вышестоящий объект: ООО Маяк


Для полноты картины:
-Азербайджан
-Грузия
-Германия
-.... и т.д.
-Россия:
1. ООО "Маяк" (Россия)
 1.1. ООО "Филиал 1 маяка"
 1.2. ООО "Филиал 2 маяка"

На сервере №1
-Азербайджан
-Грузия
-Германия
-.... и т.д.
-Россия:
1. ООО "Маяк"

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

5. Вам виднее - по каким критериям проверять, это нужно спросить у эксперта в предметной области. Я вижу сейчас две проблемы:
* Вы не сверяете Расположение (классификатор стран), что безусловно нужно делать.
* Что будете делать, если в базе приемника будет два объекта с одинаковым именем? А такое обязательно будет с подходом без уникальных идентификаторов.

1. Спасибо. Предполагается что будет так: Каждый объект внутри сервера будет иметь свой уникальный идентификатор (suid). UUiD ассоциирован с suid. При отправке этого объекта на другой сервер, отправляется UUiD
В момент получения объекта другой сервер проверяет на наличие объекта с указанным идентификатором UUiD.
Если есть сопадения, осуществляется запись. Если совпадения нет, переход в проверке по:
-странам
-по наименованию и т.д.

5. Если будет два объекта с одинаковым именем...
Уникальный идентификатор (suid) частично не решит эту проблему... На каждом сервере заводится объект. Как сервер может привести идентификатор к единому на каждом сервере в момент заведения объекта в систему? По моему никак. Пример: На сервере №1: завели объект ООО "Маяк" ему присвоен уникальный идентификатор 0089.
На другом сервере №2 - завели объект ООО "Маяк", ему ведь не присвоиться тотже самый идентификатор? а скорее всего будет другой 1254.

Как вариант, наверное при получении объекта из другого сервера, после записи. Уникальный идентификатор этого объекта сохраниться.
Пример:
Есть объекты: сервер №1 объект ООО "Маяк" уникальный идентификатор 0089.
сервер №2 - объект ООО "Маяк"идентификатор 1254.

Получен с сервера №1 на сервер№2 объект. Осуществляется запись, идентификатор объекта на сервере №2 меняется на номер идентификатора сервера №1. После чего:
сервер №1 - объект ООО "Маяк" уникальный идентификатор 0089.
сервер №2 - объект ООО "Маяк"идентификатор 0089

Может так?

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

5. Вам виднее - по каким критериям проверять, это нужно спросить у эксперта в предметной области. Я вижу сейчас две проблемы:
* Вы не сверяете Расположение (классификатор стран), что безусловно нужно делать.
* Что будете делать, если в базе приемника будет два объекта с одинаковым именем? А такое обязательно будет с подходом без уникальных идентификаторов.

Оооооооо, уже начались вариации, во время продумывания

Я не спец в MDM, но эта проблема явно как-то решается по-другому...
Я бы выделил отдельно MDM систему для таких задач с НСИ.

Если не получается, то сделать псевдо MDM:
1. Выверить все базы и присвоить объектам уникальные идентификаторы, кот бьются между базами
2. Сделать одну базу, кот будет эталоном, псевдо MDM
3.1. Или заводить все НСИ в этой эталонной базе
3.2. Или если это невозможно, то при создании объекта в другой базе, проверять на наличие в эталонной, если нет в ней, то заводить новый элемент в двух базах и присваивать уникальный идентификатор в эталоне и в базе создателе.
4. При перекачке сверять только по ИД

Посмотрите эти две презы (возможно потом еще почитайте про MDM), м.б. наведет на какие-то мысли, кот вам подходят:
http://www.slideshare.net/croc-library/mdm-47721624
http://www.slideshare.net/croc-library/mdm-47721605

Спасибо! Скорее всего это то что нужно.
А проверять на наличие эталонной по какому принципу? по стране и наименованию?

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

О, сколько нам открытий чудных готовит распределенное ведение НСИ без возможности проверок он-лайн...

Можно зайти с такой стороны:
1. Разработать, издать и внедрить правила именования новых объектов в Системе. За несоблюдение бить нещадно.
2. Продумать систему статусов новых объектов. Где "черновик" (для вновь введенных), а где полноценный, одобренный свыше объект.
3. Продумать систему распространения обновлений справочника объектов на все сервера.
4. Продумать алгоритмы сравнения (там не только с наименованиями и ОПФ будут проблемы, там еще и уровни иерархии напутают).
5. Посадить специально обученных людей разруливать коллизии и спорные ситуации по результатам отработки алгоритмов из п.4.
...и прочая, и прочая.

6. Или, гораздо лучше, разориться хотя бы на мобильную связь, забить на пп.1-5 и сделать нормальный централизованный учет.

Сверка по названию - плохая практика.

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

О, сколько нам открытий чудных готовит распределенное ведение НСИ без возможности проверок он-лайн...

Ну не так страшен черт, как его малюют, если в системе есть нормальные механизмы обьектной репликации. Имел опыт реализации схем ведения НСИ в региональных узлах без online связи с центром. Каждый элемент НСИ вводится в регионом узле, через систему обьектной репликации передается в центр, там проходит все необходимые проверки, а потом тиражируется в регионы.

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

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

Для реализации механизма обработки коллизий у элементов НСИ должно быть два ID - один внутренний, технический (какой-нибудь ROW( 8 ), маскированный идентификатором узла сети), и внешний, который польователю показывается.

Насколько я понимаю в 1С примерно так же филиальная система поддерживается.

В 90е - 0е зачастую со связью было совсем не густо, поэтому крутились как могли

Ну не так страшен черт, как его малюют, если в системе есть...

И дальше следует перечень тех самых открытий, которые автору темы еще предстоит сделать. )

В 90е - 0е зачастую со связью было совсем не густо, поэтому крутились как могли

Именно. Мои познания оттуда же.
А вообще, задача практически реликт девяностых-нулевых. Автору сильно "повезло".

И дальше следует перечень тех самых открытий, которые автору темы еще предстоит сделать. )

Именно. Мои познания оттуда же.
А вообще, задача практически реликт девяностых-нулевых. Автору сильно "повезло".

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

Аминь.

Ну так в нашем случае про полномасштабную речи нет, автор не потянет пока. Да там и коллективу авторов несладко придется.