Проблема: При получении из другого сервера данные по умолчанию сливаются в БД (т.е. происходит замена существующих данных на поступившую). Но если сервер не найдет присланные данные об объекте в текущем сервере создаст новый объект (возможно будет дубль данных)

Нужно: чтобы система при получении из другого сервера данные
а) находила аналогичный объект в базе данных текущего сервера
б) если найдет, не стирала текущие данные, а с помощью сопоставления заменяла/дополняла данные.

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

Но если понял, то она решена и описана много-много лет назад. К сожалению, об этой книге почти никто не знает. Книга: "Developing Time-Oriented Database Applications in SQL" от дремучего 2000 года. На хабре утверждают, что сейчас она раздается бесплатно. https://habrahabr.ru/post/191312/

Смысл в том, что объект не может быть ни закрыт, ни изменен. Но может быть закрыта текущая версия объекта и выпущена новая. Это не только решает вашу проблему на уровне элементарных правил, но и позволяет делать много фокусов, вроде ввода нового значения классификатора будущим периодом (актуально для тарифов, изменяющихся в будущем).

Кстати, хорошая идея реализации. А есть ли эта книга на русском языке?

Книга: "Developing Time-Oriented Database Applications in SQL" от дремучего 2000 года. На хабре утверждают, что сейчас она раздается бесплатно. https://habrahabr.ru/post/191312/

Смысл в том, что объект не может быть ни закрыт, ни изменен. Но может быть закрыта текущая версия объекта и выпущена новая. Это не только решает вашу проблему на уровне элементарных правил, но и позволяет делать много фокусов, вроде ввода нового значения классификатора будущим периодом (актуально для тарифов, изменяющихся в будущем).

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

С сервера №2 поступает  на сервер №1 сведения:
ООО Маяк
Количество сотрудников: 690
Дата получения информации: 10.10.2016

С сервера №3 поступает на сервер №1 сведения:
ООО Маяк
Месторасположение: Россия
Дата получения информации: 11.10.2016

С сервера №4 поступает на сервер №1 сведения:
ООО Муяк
Месторасположение: Россия
Координаты: 45 45 545, 5454
Сотрудников: 1000 человек
Дата получения информации: 10.10.2016

В итоге на сервере должно быть запись (результат сопоставлений и т.д.):
ООО Маяк
Месторасположение: Россия
Координаты: 45 45 545, 5454
Сотрудников: 1000 человек

Смысл в том, что объект не может быть ни закрыт, ни изменен. Но может быть закрыта текущая версия объекта и выпущена новая. Это не только решает вашу проблему на уровне элементарных правил, но и позволяет делать много фокусов, вроде ввода нового значения классификатора будущим периодом (актуально для тарифов, изменяющихся в будущем).

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

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

Накапливать изменения можно примерно в такую базу:

ID обьекта
ID атрибута обьекта
Значение атрибута
ID источника (Номер сервера)
DateStamp (время изменения)

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

Похожий подход применяют при работе ETL процедур при построении BI систем

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

С сервера №2 поступает  на сервер №1 сведения:
ООО Маяк
Количество сотрудников: 690
Дата получения информации: 10.10.2016

С сервера №3 поступает на сервер №1 сведения:
ООО Маяк
Месторасположение: Россия
Дата получения информации: 11.10.2016

С сервера №4 поступает на сервер №1 сведения:
ООО Муяк
Месторасположение: Россия
Координаты: 45 45 545, 5454
Сотрудников: 1000 человек
Дата получения информации: 10.10.2016

В итоге на сервере должно быть запись (результат сопоставлений и т.д.):
ООО Маяк
Месторасположение: Россия
Координаты: 45 45 545, 5454
Сотрудников: 1000 человек

Накапливать изменения можно примерно в такую базу:

ID обьекта
ID атрибута обьекта
Значение атрибута
ID источника (Номер сервера)
DateStamp (время изменения)

Нет, нет и нет. Коллеги, не изобретайте велосипед. Просто делайте, как написано в книге.

В итоге на сервере должно быть не менее трех записей. Примерно так:

Численность местоположение Координаты StartDate EndDate
690			10.10.2016 11:12:43	11.10.2016 05:17:55
690	Россия		11.10.2016 05:17:56	12.10.2016 08:19:55
				12.10.2016 08:19:56

01.01.2200 00:00:00
Таблицы на форуме глючат, смотрите книгу.
Есть ли она на русском - мне про то ничего неизвестно.

Нет, нет и нет. Коллеги, не изобретайте велосипед. Просто делайте, как написано в книге.

Если уж брать что-то за основу, так DDS

https://en.wikipedia.org/wiki/Data_Distribution_Service