Невероятный кошмар базы данных MySQL

Question

Table1: Все, включая кухонную раковину. Даты в неправильном формате (год последний, поэтому вы не можете сортировать по этому столбцу), числа, хранящиеся в виде VARCHAR, полные адреса в столбце «улица», имя и фамилия в столбце имени, город в столбце фамилии, неполные адреса, строки, которые обновить предшествующие строки, перемещая данные из одного поля в другое на основе некоторого набора правил, которые изменились за эти годы, дублированных записей, неполных записей, записей мусора ... вы называете это ... о, и, конечно, не TIMESTAMP или PRIMARY КЛЮЧЕВАЯ колонка в поле зрения.

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

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

Таблица 4: была описана как работа в процессе и может быть изменена в любой момент. Это существенно похоже на других.

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

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

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

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

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

Ситуация немного деликатная, поскольку у них есть некоторая ценная информация, которую моя компания очень хочет. Я был послан высшим руководством крупной корпорации (вы знаете, как они), чтобы «сделать это».

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

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

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

Ваши мысли будут высоко оценены.

Answer 1

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

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

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

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

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

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

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

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

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

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

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

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

Answer 2

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

Answer 3

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

Answer 4

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

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

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

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

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