Как разрешить конфликт данных

Question

У меня есть несколько баз данных и вам нужны обменные данные между ними. Когда я экспортирую из db A import в db B, произойдет конфликт Id. Я думаю о двух подходах, меня никто не удовлетворяет.

1. выберите max (id), затем создайте новый идентификатор, чтобы избежать конфликта, но один столбец хранит структуру json и содержит идентификатор тоже! (история причина). Поэтому мне нужно создать новый идентификатор (первичный ключ) и изменить все идентификаторы в этом столбце json.

2. или я могу добавить информацию о партии для каждого импорта данных. Когда я импортирую данные, я обнаруживаю каждый id в sql и добавляю перед ним пакетный идентификатор. Такие, как:

оригинальный дб как:

ID  COL_JSON 
11  {id:11,name:xx ...} 

Я хочу, чтобы вставить новую запись: 11, после вставки добавить пакетную информацию «1000» перед идентификатором

Теперь дб выглядит как

ID  COL_JSON 
11  {id:11,name:xx ...} 
100011 {id:100011,name:xx ...} 

следующая партия будет 1001,1002 1003 ..., поэтому, если новый 11 записи должны быть вставить дб выглядит

ID  COL_JSON 
11  {id:11,name:xx ...} 
100011 {id:100011,name:xx ...} 
100111 {id:100111,name:xx ...} 

Хотя оба подхода могут разрешить конфликт, я считаю, что два подхода глупы. Есть ли какая-то изящная схема?

Answer 1

Для устаревшей системы нет лучшего подхода, кроме как выровнять его. Мы не можем больше изменить его на устаревшую систему, поэтому ваш 2-й подход кажется хорошим. Честно говоря, это не глупо и просто правильный путь.

Answer 2

Я не совсем понимаю, что ваши базы данных меняют.

Если вам нужны данные из обеих баз данных в обоих из них, вы можете использовать что-то похожее на свою партию, но используя символы - A11 и B11 ids.

Таким образом, у вас не будет конфликтов, даже если ваша база данных будет расти.

Редактировать: вы также можете сделать первичный ключ с двумя полями: идентификатор целого числа с автоинкрементами и varchar для исходного имени базы данных.

Answer 3

Когда у меня есть таблица, которая должна быть синхронизирована (не на ходу), я использую этот подход:

• Основная таблица, которая будет перезаписана имеет большой автоинкрементного (то есть: автоинкрементного = 100000)
• вторичная таблица, которая будет объединена с основной, имеет нормальный автоинкрементного, начиная с 1.

Единственное требование состоит в том, что вы убедитесь, что основная таблица имеет достаточно большой autocrement настройке, так что вторичный таблица id wi ll никогда не доходите до главного стола. ID