Слияние данных при сохранении отношений в SQL Server - PullRequest
0 голосов
/ 04 ноября 2010

Сценарий, который у меня есть, заключается в том, что несколько компьютеров с локальными экземплярами SQL Server 2008 будут генерировать данные с использованием таблиц с целочисленными полями идентификации.Эти данные будут иметь связанные записи, связанные с этими полями целочисленного идентификатора.Данные должны быть объединены с нескольких компьютеров в одну базу данных на центральном сервере с одинаковой структурой (чтобы один и тот же код отчетности мог работать с любой базой данных), при этом должным образом поддерживая связи между связанными записями.

Как(вымышленный) пример, скажем, все ПК записывают аспекты погоды.Каждые 10 минут в таблице WeatherInspection создается запись.Здесь есть поле идентификатора целочисленного идентификатора.В WeatherInspectionItems также создается ряд записей, содержащих температуру на нескольких различных датчиках температуры.Эти записи связаны с таблицей WeatherInspection полем ID.Это не реальный сценарий, но иллюстрирует принцип - родительская таблица с полем целочисленного идентификатора, дочерняя таблица связана с этим идентификатором.На практике существует гораздо больше связанных таблиц, каждая из которых имеет поле с внутренним идентификатором.

Затем мне нужно объединить WeatherInspection и WeatherInspectionItems со всех ПК в центральную базу данных SQL Server 2008.Поскольку каждый ПК имеет свои собственные поля идентификаторов, каждый ПК мог бы использовать те же идентификаторы в своей таблице WeatherInspection.

Во время объединения мне нужно иметь возможность назначить новое значение идентификатора для записей WeatherInspection, чтобы ониостаются уникальными в базе данных master, но для меня большая проблема заключается в том, что мне также нужно иметь возможность изменять значение в дочерних записях, чтобы они связывались с новым полем ID.

Я хочу иметь возможность:

  1. Продолжайте использовать идентификаторы int вместо переключения на GUIDS
  2. Поддерживать одинаковую структуру базы данных в обеих БД
  3. Хранить идентификаторы int в качестве единственного поля первичного ключа

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

Я знаю, что яможет иметь составные первичные ключи локально с идентификатором компьютера или чем-то подобным, но из-за инструментов ORM мы можем бытьПойте, что нужно одно поле int ID, я стараюсь избегать составных ключей и идентификаторов GUID.

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

Спасибо!

Ответы [ 3 ]

0 голосов
/ 04 ноября 2010

GUID может показаться самым простым способом, но если вы настаиваете на использовании сгенерированных идентификаторов, то это возможно, если ваш ORM использует SQL Server SEQQUENCE для получения идентификаторов.

Все, что вам нужно, это установить IDENTITY (start, 1), чтобы иметь определенный стартовый номер для всех таблиц на данном сервере - с другим «start» для другого сервера. 0 на сервере1, 1000000 на сервере два, 2000000 на сервере 3 и т. Д.

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

Это решение ограничено и будет работать только для небольшого числа серверов, ожидающих <1000000 строк в любой одной таблице. </p>

Как я уже сказал, GUIDS кажутся лучшим решением.

0 голосов
/ 14 мая 2014

Не может ли инструмент SQL Data Compare от RedGate предложить решение здесь?

0 голосов
/ 04 ноября 2010

С помощью MS Sync Framework вы можете перехватить данные, прежде чем они попадут в базу данных.

Я не уверен, возможно ли это с помощью репликации слиянием.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...