Абсолютный кошмар устаревшей базы данных MySQL

Question

Таблица 1:Все, включая кухонную раковину.Даты в неправильном формате (последний год, поэтому вы не можете выполнить сортировку по этому столбцу), Числа, сохраненные как VARCHAR, полные адреса в столбце "улица", имя и фамилия в столбце firstname, город в столбце lastname, неполные адреса, строки, которые обновляют предшествующие строки путем перемещения данных из одного поля в другое на основе некоторого набора правил, которые менялись с годами, повторяющиеся записи, неполные записи, мусорные записи...вы сами это называете...о, и, конечно же, в поле зрения нет метки ВРЕМЕНИ или столбца ПЕРВИЧНОГО КЛЮЧА.

Таблица 2:Любая надежда на нормализацию улетучилась, когда я вскрыл этого ребенка.У нас есть строка для каждой записи И обновления строк в первой таблице.Таким образом, дубликаты типа "завтра не наступит" (стоимостью 800 МБ) и столбцы типа Phone1 , Phone2 , Phone3 , Phone4 ...Phone15 (они не называются phone.Я использую это для иллюстрации) Ключ foriegn - это..что ж, попробуй угадать.Есть три кандидата, в зависимости от того, какие данные были в строке таблицы 1

Таблица 3:Может ли это стать еще хуже?Ах да."Внешний ключ - это комбинация столбцов VARCHAR, состоящая из тире, точек, цифр и букв!если это не обеспечивает совпадения (чего часто не происходит), то следует ввести второй столбец аналогичного кода продукта.Столбцы, названия которых НЕ имеют отношения к данным внутри них, и обязательный номер Phone1, Phone2, Phone3, Phone4...Телефон15.Есть столбцы, дублированные из Таблицы1, и в поле зрения нет ВРЕМЕННОЙ МЕТКИ или столбца ПЕРВИЧНОГО КЛЮЧА.

Таблица 4:было описано как незавершенная работа, которая может быть изменена в любой момент.Это, по сути, то же самое, что и все остальные.

В рядах, близких к 1 му, это БОЛЬШОЙ беспорядок.К счастью, это не мой большой беспорядок.К несчастью, мне приходится извлекать из этого композитную запись для каждого "клиента".

Первоначально я разработал четырехэтапный перевод Таблицы1, добавив ПЕРВИЧНЫЙ КЛЮЧ и преобразовав все даты в сортируемый формат.Затем еще пара шагов запросов, которые возвращали отфильтрованные данные, пока у меня не была таблица 1, куда я мог бы использовать ее для извлечения из других таблиц для формирования композиции.После нескольких недель работы я свел это к одному шагу, используя несколько трюков.Итак, теперь я могу указать своему приложению на беспорядок и вывести красивую чистую таблицу составных данных.К счастью, для моих целей мне нужен только один из телефонных номеров, поэтому нормализация моей таблицы не является проблемой.

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

Поскольку существующие строки в любой из таблиц могут быть изменены, и поскольку в столбцах ОБНОВЛЕНИЯ нет ВРЕМЕННЫХ меток, мне придется прибегнуть к журналам, чтобы узнать, что произошло.Конечно, это предполагает, что существует двоичный журнал, которого там нет!

Представление концепции пошло ко дну, как свинцовый воздушный шар.С таким же успехом я мог бы сказать им, что их детям придется пройти экспериментальную операцию.Они не совсем высокотехнологичны...на случай, если вы еще не поняли...

Ситуация немного щекотливая, поскольку у них есть кое-какая ценная информация, которая очень нужна моей компании.Высшее руководство крупной корпорации (вы же знаете, какие они) послало меня "сделать так, чтобы это произошло".

Я не могу придумать никакого другого способа обработки ночных обновлений, кроме как проанализировать файл журнала bin с помощью еще одного приложения, чтобы выяснить, что они сделали с этой базой данных в течение дня, а затем соответствующим образом скомпоновать мою таблицу.Мне действительно нужно только взглянуть на их таблицу1, чтобы понять, что делать с моей таблицей.Другие таблицы просто предоставляют поля для удаления записи.(Использование MASTER SLAVE не поможет, потому что у меня будет дубликат беспорядка.)

Альтернативой является создание уникального хэша для каждой строки их таблицы1 и построение хэш-таблицы.Затем я бы просматривал ВСЮ базу данных каждую ночь, проверяя, совпадают ли хэши.Если они этого не сделают, я бы прочитал эту запись и проверил, существует ли она в моей базе данных, если да, то я бы обновил ее в своей базе данных, если нет, то это новая запись, и я бы вставил ее.Это некрасиво и небыстро, но разбор двоичного файла журнала тоже не из приятных.

Я написал это, чтобы помочь разобраться в проблеме.часто рассказ об этом кому-то другому помогает прояснить проблему, делая решение более очевидным.В этом случае у меня просто еще больше болит голова!

Мы были бы очень признательны за ваши мысли.

Answer 1

Файлы журналов (двоичные журналы) тоже были моей первой мыслью.Если бы вы знали, как они это делают, вы бы содрогнулись.Для каждой строки в журнале есть много-много записей по мере добавления и изменения фрагментов.Он просто ОГРОМНЫЙ!На данный момент я остановился на хэш-подходе.При некоторой умной подкачке файловой памяти это происходит довольно быстро.

Answer 2

Я не специалист по MySQL, так что это выходит из левого поля.

Но я думаю, что файлы журналов могут быть ответом.

К счастью, вам действительно нужно знать только 2 вещи из журнала.

Вам нужна запись / rowid, и вам нужна операция.

В большинстве баз данных, и я предполагаю, что MySQL, в каждой строке есть неявный столбец, например rowid или recordid, или что-то еще.Это внутренний номер строки, используемый базой данных.Это ваш "бесплатный" первичный ключ.

Далее вам нужна операция.В частности, является ли это операцией вставки, обновления или удаления строки.

Вы объединяете всю эту информацию во временном порядке, а затем просматриваете ее.

Для каждой вставки / обновления вы выбираете строку из вашей исходной базы данных и вставляете / обновляете эту строку в вашей целевой базе данных.Если это удаление, то вы удаляете строку.

Вас не волнуют значения полей, они просто не важны.Проделайте весь ряд.

Надеюсь, вам не придется "разбирать" двоичные файлы журналов, у MySQL уже должны быть процедуры для этого, вам просто нужно найти и выяснить, как их использовать (возможно, даже есть какая-нибудь удобная утилита "дамп журнала", которую вы могли бы использовать).

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

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

Answer 3

Разве вы не можете использовать существующий код, который обращается к этой базе данных, и адаптировать его к вашим потребностям?Конечно, код, должно быть, ужасен, но он мог бы разберитесь со структурой базы данных за вас, не так ли?Надеюсь, тогда вы могли бы сосредоточиться на выполнении своей работы, а не играть в археолога.

Answer 4

возможно, вы сможете использовать инструмент mk-table-sync от maatkit для синхронизации промежуточной базы данных (в конце концов, ваша база данных очень мала).Это "дублирует беспорядок".

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

Я полагаю, что это можно было бы делать ежедневно без проблем с производительностью.

Выполнение всего этого с другого сервера позволит избежать воздействия на исходную базу данных.

Единственная проблема, которую я вижу, заключается в том, что некоторые таблицы не имеют первичных ключей.