При слиянии записей базы данных сколько бумажного следа мне оставить? - PullRequest
0 голосов
/ 31 декабря 2011

Много дублирования проникло в базу данных клиента из-за плохого начального дизайна. Я пишу некоторые хранимые процедуры для объединения пользователей и т. Д. Было бы неплохо выполнить объединение и при этом иметь возможность отменить или выполнить откат без полного восстановления базы данных.

Мой первоначальный вопрос заключался в том, сколько еще мне нужно заниматься домашним хозяйством или делопроизводством и как мне это делать? Я думаю, что я обратился к этому. Вопрос сейчас в том, нужно ли что-то делать, кроме следующего. Теперь я понимаю, что это был плохой вопрос для этого сайта. В качестве компенсации за это я предложу поделиться своим опытом со всеми, кому также необходимо создать инструмент слияния дубликатов записей.

Основной псевдокод для слияния:

  1. Пусть from_id = запись для слияния (mergee). Пусть into_id = запись, на которую должны ссылаться все ссылки from_id после слияния.

  2. Проверить схему базы данных по известным параметрам и вернуть ошибку schema_changed, если она была изменена.

  3. Используйте информацию в таблицах merge_config и merge_referrer_config, чтобы добавить запись в таблицы merge_log и merge_referrer_log, чтобы дать подробные инструкции для каждого фрагмента данных, который необходимо изменить для выполнения объединения. Этот журнал становится инструкциями для отката (отменить). Таблицы конфигурации предоставляют полную информацию о том, где ссылки на записи слияния упоминаются в базе данных.

  4. Следуйте инструкциям, только что добавленным в таблицы журнала слияния, чтобы обновить все соответствующие (как определено в таблицах merge_config и merge_referrer_config) таблицы, чтобы установить соответствующие столбцы = into_id, где соответствующий столбец = from_id.

  5. Пометьте столбец merged_to записи для from_id значением into_id.

Спасибо, Том

1 Ответ

1 голос
/ 31 декабря 2011

Ну, вы все равно должны сделать резервную копию, на случай, если что-то пойдет не так.

С точки зрения контрольного журнала, я бы соблазнился таблицей дубликатов с дополнительным столбцом для того, когда он получил«слиться», то дом держать это.Скажите Чаку любую вещь, более чем X старая, из дубликатов перед запуском слияния.Другой вариант, который я видел, - это взвешивание того, насколько разные записи.«Точный дубликат» - это 0, все по-другому, но ключ - 100. Затем бросьте / продолжайте в зависимости от взвешивания.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...