MySQL - перенос некоторых идентификационных номеров со случайно сгенерированных на автоинкрементные - PullRequest
Новая
       14

MySQL - перенос некоторых идентификационных номеров со случайно сгенерированных на автоинкрементные

0 голосов
/ 09 ноября 2011

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

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

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

Возможно ли такое с MySQL без каких-либо проблем?В настоящее время я использую два столбца - один, наш логический идентификатор автоинкрементации, и второй столбец с именем old_id, который использовался во время миграции.Но нам нужно, чтобы сотрудники колл-центра использовали только один ID, иначе возникнет массовая путаница.

Спасибо!

Ответы [ 2 ]

2 голосов
/ 09 ноября 2011

Если вы начинаете нумерацию с самого высокого случайного значения, достаточно просто изменить поле на автоинкремент, нормальное поведение состоит в том, что mysql не будет изменять уже установленные идентификаторы и начинает нумерацию с самого высокого значения + 1.

Если вы хотите начать с определенного значения (скажем, 10 000 000), вы можете установить 

ALTER TABLE theTableInQuestion AUTO_INCREMENT=10000000

Конечно, обязательно создавайте резервные копии и тестируйте, но это не должно создавать никаких проблем. (Обратите внимание, что старые записи будут храниться в порядке поля id, которое является случайным и не будет отражать порядок создания.)

0 голосов
/ 09 ноября 2011

Поскольку вам нужно сохранить старые идентификаторы, я предполагаю, что вы собираетесь создать новый столбец для идентификатора автоинкремента, который станет вашим основным ключом, но сохранить существующий столбец идентификатора и переименовать его (в old_id,может быть?).Я также собираюсь предположить, что вы записали, когда клиент подписался.

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

Поиск клиента: 

SELECT *
FROM customer
WHERE (id = /*Put your ID here*/ AND reg_date >= /*Put the date the new regime starts here*/)
OR (id_old = /*put your ID here*/ AND reg_date < /*Put the date the new regime starts here*/)

Это иногда возвращает 2 строки, поэтому вам придется использовать некоторые другие критерии для уникальной идентификации данного клиента.

Что касается связи старого клиента с другими таблицами в базе данных, вы всегда можете использовать новый идентификатор внутри всей БД после ее создания.Очевидно, вам придется обновить таблицы, которые используют старый идентификатор в качестве внешнего ключа.

UPDATE target_table 
JOIN customers on target_table.cust_id = customers.id_old
SET target_table.cust_id = customers.id;

(Примечание. Выше приведен простой и грязный запрос, который еще не был протестирован! Я бы предложил протестировать копию базы данных, прежде чем вы попробуете ее по-настоящему!)

...