Сначала конфликт ключей указывает на то, что любой процесс, который вы используете в данный момент, является плохим.
Чтобы правильно объединить две базы данных, использующие автоматически сгенерированные (non_GUID) ключи, вам необходимо выполнить несколько шагов. Сначала добавьте новый автоматически сгенерированный ключ в родительскую таблицу, затем импортируйте все данные из обеих таблиц, переименуйте старый старый файл в ID_old и переименуйте новые файлы в старое имя идентификатора. В этот момент вы можете перейти на дочерние столы. Вам нужно будет скопировать в дочерние таблицы, присоединившись к родительской таблице и приняв новое поле идентификатора в качестве значения для внешнего ключа вместо значения в существующей таблице. Вам нужно будет повторить этот процесс для каждой таблицы внешнего ключа, и если эта таблица также является родительской таблицей, вам нужно будет добавить поле преобразование в таблицу, прежде чем копировать какие-либо данные, чтобы вы могли работать по всей цепочке. , Чтобы сделать это правильно, требуется много знаний о структуре базы данных и много планирования. Не стоит делать это без хорошей резервной копии обеих исходных баз данных. Также лучше, если этот процесс может произойти, когда обе базы данных находятся в однопользовательском режиме.
Если вы используете естественные ключи и у вас есть дубликаты, у вас будет совсем другая проблема. Все дубликаты записей ключей должны быть сначала перенесены в отдельную таблицу, и необходимо определить, какие данные являются более правильными. В некоторых случаях вы обнаружите, что естественный ключ на самом деле не уникален (они редко бывают, поэтому я почти никогда не использую их), и объединенная база данных должна будет работать с автоматически сгенерированным ключом некоторого типа. Это будет связано как с изменениями кода, так и с изменениями базы данных, так что это вариант последней инстанции.
Что часто встречается с естественными ключами, так это то, что данные для каждого из них разные, но симлиарные (улица Святого Вице в адресе) в этом случае отмечают одну из записей для вставки, а затем, когда вставка выполняется в два этапа, сначала записи, которые не имеют дубликатов, а затем записи в таблице дубликатов, помеченные для вставки. Помните, что вам придется проверять все записи во всех таблицах внешнего ключа, чтобы определить, что сохранить, а что нет. Просто выбрасывать дубликаты - плохая идея, и вы потеряете данные таким образом, возможно, важные данные (например, заказы клиента). Это долгий утомительный процесс, который потребует от человека, обладающего знаниями в области данных, решений. Как программист, вы должны предоставить им инструмент дедупликации, который позволит им исследовать все данные для каждого набора дубликатов и выбрать, что сохранить и от чего избавиться, а затем пометив все, он запустит процесс вставки записей. , Помните в своем проекте, что для истинных дубликатов будут некоторые дочерние таблицы (например, заказы), которым нужны записи из обеих отправленных в базу данных для записи, выбранной в качестве входной (заказы - пример), для других таблиц Вы захотите выбрать, какой из них правильный (например, адрес). Таким образом, вы можете видеть, что это сложный процесс, требующий глубокого понимания базы данных.
Если у вас много дубликатов, они могут очищать и добавлять данные в течение нескольких месяцев, поэтому инструмент действительно важен. Люди, которые делают это, скорее всего, будут пользователями системы, а не специалистами по базам данных или программистами, так как они единственные, кто действительно может принять решение о том, какую запись вести. Скорее всего, вам нужно будет сделать что-то похожее в любом случае, так как могут быть записи, которые являются дубликатами, даже если у вас есть автоматически сгенерированный ключ. Их просто сложнее найти.
Нет простого способа объединить две базы данных (даже при использовании GUIDS у вас есть проблема с дубликатами в естественном ключе).