Вопрос по database, mysql – Невероятный кошмар базы данных MySQL

10

Таблица 1: Все, включая кухонную раковину. Даты в неправильном формате (последний год, поэтому вы не можете сортировать по этому столбцу), числа, хранящиеся в виде VARCHAR, полные адреса на «улице». столбец, имя и фамилия в столбце имени, город в столбце фамилии, неполные адреса, строки, которые обновляют предыдущие строки путем перемещения данных из одного поля в другое на основе некоторого набора правил, который изменился за последние годы, дублированные записи, неполные записи , записи мусора ... вы называете это ... о, и, конечно, не столбец TIMESTAMP или PRIMARY KEY в поле зрения.

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

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

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

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

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

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

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

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

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

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

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

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

Ваши мысли будут с благодарностью.

Ваш Ответ

4   ответа
1

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

2

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

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

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

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

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

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

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

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

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

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

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

0

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

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

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

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

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

The only problem I can see is if some of the tables don't have primary keys. - Что они не делают ... После сегодняшних разговоров мне сказали, что они "редко" обновить / удалить записи ... что бы это ни значило. В разговоре с другим разработчиком базы данных кажется, что лучший (единственный) способ сделать это правильно - это хэшировать каждую чертову строку и сохранять хеш в таблице. Затем каждую ночь перечитывайте ВСЮ базу данных, создавая хэш для каждой строки, и просто выполняйте простое сравнение. Я просто не могу найти способ обойти это. Попытка расшифровать двоичные файлы журналов будет просто чревата опасностью. Mike Trader
1

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

Похожие вопросы