Слияние двух таблиц SQL с конфликтами ключей

Question

Я пытаюсь объединить две таблицы с одинаковой структурой. В известном блоке строк первичный ключ (целое число auto_increment) используется в обеих таблицах для разных данных. Скажем, это строки с первичными ключами 2000-2150. Каков наилучший способ перенумеровать эти записи в таблице B на неиспользуемые значения (скажем, в диапазоне выше 3000), чтобы слияние продолжалось без конфликтов? Должен ли я просто ОБНОВИТЬ их на месте (например, добавив 1000 к каждому идентификатору в этом диапазоне), или есть ли лучшие способы?

Примечания:

1. Все ссылки на эту таблицу объявляются ON UPDATE CASCADE, так что я могу спокойно пронумеровать их без последствий.

2. Остальное слияние, с которым я могу справиться. Обе таблицы содержат полезные данные, и когда ключ за пределами этого диапазона повторяется, я буду держать версию в таблице А.

Answer 1

Изменение числа к отрицательному числа будет работать. Не было бы шансов на столкновение сейчас или в будущем.

Answer 2

Перейдите от комментария к ответу.

Если бы вы могли, пожалуйста, предоставьте запрос, который вы сейчас пытаетесь, чтобы у нас было что-то, с чем можно было работать. Тем не менее, как короткий ответ ...

В вашем выборе таблица B вы можете:

select Id, col2, col3, col4 
from TableA 
union all 
select Id + 3000, col2, col3, col4 
from TableB; 

То есть, если столбец Id числовой.

Следует отметить, что если вы попытаетесь вставить эти записи в Table A, вам необходимо отключить автоматическую последовательность.

Другой вариант, если вы собираетесь вставлять записи в Table A из Table B, откладывая возможные проблемы осиротевших детей записей из Table B, можно опустить Id столбец из Table B на SELECT INTO TableA..., когда вы делаете вставку, новое значение Id будет сгенерировано с идентификатором автоинкремента.

Для выдачи сиротских дочерних записей, вы также можете добавить новый столбец TableA под названием TableBId, который разместится оригинальный IdTableB из которых позволит вам получить доступ старых данных, связанных с TableB.Id. Другой альтернативой будет новая детская таблица для этой же идеи. Это помешает вам изменить структуру вашего TableA, но при этом по-прежнему обеспечит некоторый способ сохранения доступа к вашим старым данным.

Если бы у вас была больше информации о том, чего вы хотите в конечном счете, мы могли бы предложить гораздо лучшее решение, но это должно вас начать.

Answer 3

Определить значение идентификаторов, которые "дублирующие"

SELECT b.id 
    FROM b 
    JOIN a 
    ON b.id = a.id 

Определить новый "идентификатор" значение

SELECT MAX(m.id) 
    FROM (SELECT MAX(ma.id) AS id 
      FROM a ma 
      UNION ALL 
     SELECT MAX(mb.id) AS id 
      FROM b mb 
     ) m  

Сформировать новый "неиспользованный" идентификатор значение

SELECT s.id   AS old_id 
     , @id := @id + 1 AS new_id 
    FROM (SELECT b.id 
      FROM b 
      JOIN a 
       ON b.id = a.id 
      ORDER BY b.id 
     ) s 
CROSS 
    JOIN (SELECT @id := MAX(ma.id) FROM a ma) i 
ORDER 
    BY s.id 

Выполните обновление

UPDATE b t 
    JOIN (SELECT r.* 
      FROM (SELECT s.id   AS old_id 
         , @id := @id + 1 AS new_id 
        FROM (SELECT b.id 
           FROM b 
           JOIN a 
           ON b.id = a.id 
          ORDER BY b.id 
         ) s 
        CROSS 
        JOIN (SELECT @id = MAX(m.id) 
          FROM (SELECT MAX(ma.id) AS id 
             FROM a ma 
            UNION ALL 
            SELECT MAX(mb.id) AS id 
             FROM b mb 
           ) m  
         ) i 
        ORDER 
         BY s.id 
       ) r 
     ) q 
    ON t.id = q.old_id 
    SET t.id = q.new_id 

Answer 4

если вы делаете это более регулярно, попробуйте некоторые фантазии способ, как другие описывают, если это получить вещи сделать один таймер, просто сделать это легкий путь, и убедитесь, что вы не нарушаете ничего:

• создать MySQL дамп
• отключить скрипты писать а и б
• отключить AUTO_INCREMENT
• caculate смещение (мин ID от б - макс ID от + 1)

• записей починки в б (если каскадные работы)

  обновление б набор b.id = b.id + смещение где b.id в (выберите идентификатор из)

• починки auto_increment обеих таблиц (устанавливается за последней записи)
• позволяют auto_increment
• включить скрипт, который записывает в таблицу сообщение об ошибке
• производят в скрипт, который пытается писать в таблицу Ь, объясняя, что данные объединены с (или просто использовать таблицу там тоже)
• переименования таблицы б в delete_after_2016_05_31_b

erm, что происходит с каскадными данными, которые все еще указывают на таблицу b?

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

Другой подход - перейти к записи по записи и вставить данные в таблицу a, а затем использовать mysqllastinsertid для обновления всех записей, указывающих на старое значение.