Что ж, я уверен, что этот вопрос уже задавался, но я еще не нашел ни одного надежного ответа на него. Я нахожусь в процессе создания решения, которое включает удаленные офисы, загружающие данные в одну главную базу данных через веб-сервис.
По сути, в каждом офисе будет служба Windows, которая работает примерно каждые 1 час, собирает все новые данные в набор данных, подключается к серверу по протоколу http и загружает набор данных. Затем сервер импортирует данные, и все хорошо. По идее это должно работать. Право.
Не совсем, поэтому каждый офис имеет уникальный OfficeID, который ему присваивается сервером, чтобы сохранять их уникальностью на сервере. Сначала я думал, что взломал его, пока не понял проблему с автоматическим инкрементом PK. Видите ли, все удаленные офисы уже имеют существующие данные, и все их таблицы имеют автоматическое увеличение PK и все связанные ограничения. Корневые / родительские таблицы, имеющие OfficeID, не имеют проблем, поскольку они уже уникальны, проблема связана с внешними ключами, поскольку, когда они достигнут сервера, у них будет NewID, и поэтому связь с дочерним элементом будет потеряна.
На данный момент у меня есть только 2 решения.
- Удалите все автоинкрементные и уникальные ограничения PK на БД сервера и используйте OfficeID для фильтрации дублированных внешних «ключей». или ...
- При импорте набора данных отслеживайте каждую строку и связанный с ней родительский элемент, используя такие вещи, как Scope_Identity и т. Д., Чтобы каждая дочерняя строка была связана с правильной родительской строкой.
Вариант 1 выглядит намного проще для реализации, поскольку он менее трудоемок для меня, но я думаю, что производительность sql, а также целостность данных будут проблемой, поскольку ограничения не могут быть применены. Вариант 2 будет держать вещи под контролем, но, черт возьми, объем необходимого кода невероятен.
Есть ли другие варианты, которые я не рассматриваю? и если у меня есть только 2 выше, который является меньшим из двух зол.
Спасибо
John