Нужно образец описания как вообще сопоставлять эти данные..
Огласите полный список... атрибутный состав объектов, пожалуйста.
Не-не-не... Автор попросил просто правила сопоставления данных. Весь остальной "обвес" пока за рамками.
Само сопоставление данных должно сводится к mapping (Сущность исходная, Атрибут исходный, Сущность целевая. Атрибут целевой, Правило преобразования)
Да вроде это и нужно. Можете дать какой либюо образец подобного описания?
Как описываются сопоставления, "сведение" на примере?
Иерархия многоуровневая и многокорневая.
Состав атрибутов один и тот же.
Удобнее всего это делать на диаграмме последовательсти или кооперации.
К слову. Не знаю, кому как, а для меня диаграмма последовательности с условными действиями (альтами и лупами) теряет читабельность от слова совсем. Уж лучше блок-схемы.
Возможно, задачу я не понял. Мне показалось, что вы пытаетесь изобрести велосипед с квадратными колесами, вместо треугольных. В то время, как в мире давно принято делать круглые.
Проблема: При получении из другого сервера данные по умолчанию сливаются в БД (т.е. происходит замена существующих данных на поступившую). Но если сервер не найдет присланные данные об объекте в текущем сервере создаст новый объект (возможно будет дубль данных)
Нужно: чтобы система при получении из другого сервера данные
а) находила аналогичный объект в базе данных текущего сервера
б) если найдет, не стирала текущие данные, а с помощью сопоставления заменяла/дополняла данные.
Книга: "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 (время изменения)
| ||||||
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 |
Нет, нет и нет. Коллеги, не изобретайте велосипед. Просто делайте, как написано в книге.