Table1: Все, включая кухонную раковину. Даты в неправильном формате (последний год, поэтому вы не можете сортировать по этой колонке), Числа, хранящиеся как VARCHAR, заполняют адреса в столбце "улица", имя и фамилия в столбце firstname, город в столбце lastname, неполные адреса, строки, которые обновлять предшествующие строки, перемещая данные из одного поля в другое на основе некоторого набора правил, который изменился с годами, дубликатов записей, неполных записей, записей мусора... вы называете это... ох и, конечно, не TIMESTAMP или PRIMARY KEY в поле зрения.
Table2: Любая надежда на нормализацию вышла из окна, взломав этого ребенка открытым. У нас есть строка для каждой записи И обновление строк в таблице. Так что дубликатов вроде завтра нет (стоимость 800 МБ) и таких столбцов, как Phone1 Phone2 Phone3 Phone4... Phone15 (они не называются телефонами. Я использую это для иллюстрации). Foriegn key - это... хорошо угадать. Есть три кандидата в зависимости от того, какие данные были в строке в таблице1
Таблица3: Может быть, хуже. О да. "Внешний ключ - это комбинация столбцов VARCHAR с тире, точками, цифрами и буквами! Если это не соответствует совпадению (чего часто не хватает), то второй столбец аналогичного кода продукта должен иметь. Столбцы, имеющие имена, которые несут НЕТ корреляции с данными внутри них и обязательным Phone1 Phone2 Phone3 Phone4... Телефон 15. Существуют столбцы, дублированные из Таблицы 1, а не столбцы TIMESTAMP или PRIMARY KEY в поле зрения.
Таблица 4: была описана как работа в прогрессе и может быть изменена в любой момент. Это особенно похоже на других.
Приблизительно 1 м строк это БОЛЬШОЙ беспорядок. К счастью, это не мой большой беспорядок. К несчастью, я должен вытащить из него композитную запись для каждого "клиента".
Сначала я разработал четырехэтапный перевод таблицы 1, добавив PRIMARY KEY и преобразовывая все даты в отсортированный формат. Затем еще несколько шагов запросов, которые возвратили отфильтрованные данные до тех пор, пока я не столкнулся с таблицей 1, где я мог бы использовать его, чтобы вытащить из других таблиц, чтобы сформировать композит. После нескольких недель работы я получил это на один шаг, используя некоторые трюки. Поэтому теперь я могу указать свое приложение на беспорядок и вытащить красивую чистую таблицу композитных данных. К счастью, мне нужен только один из номеров телефонов для моих целей, поэтому нормализация моей таблицы не проблема.
Однако именно здесь начинается настоящая задача, потому что каждый день сотни сотрудников добавляют/обновляют/удаляют эту базу данных способами, которые вы не хотите воображать, и каждую ночь я должен получать новые строки.
Поскольку существующие строки в любой из таблиц могут быть изменены, и поскольку нет столбцов TIMESTAMP ON UPDATE, мне придется обратиться к журналам, чтобы узнать, что произошло. Конечно, это предполагает, что существует двоичный журнал, которого нет!
Представление концепции опустилось, как свинцовый шар. Я мог бы также сказать им, что их детям придется пройти экспериментальную операцию. Они не совсем привет... на случай, если вы не собрались...
Ситуация немного тонкая, поскольку у них есть ценная информация, которую моя компания хочет плохо. Я был отправлен старшим руководством крупной корпорации (вы знаете, как это происходит), чтобы "сделать это".
Я не могу думать о каком-либо другом способе обработки ночных обновлений, чем анализировать файл журнала bin с помощью еще одного приложения, чтобы выяснить, что они сделали с этой базой данных в течение дня, а затем составьте таблицу. Мне действительно нужно только посмотреть на их таблицу1, чтобы выяснить, что делать с моим столом. Другие таблицы просто предоставляют поля для очистки записи. (Использование MASTER SLAVE не поможет, потому что у меня будет дубликат беспорядка.)
Альтернативой является создание уникального хэша для каждой строки таблицы1 и построение хеш-таблицы. Затем я каждую ночь просматривал базу данных ENTIRE, проверяя, соответствуют ли хэш-коды. Если они этого не сделают, я бы прочитал эту запись и проверил, существует ли она в моей базе данных, если это произойдет, я бы обновил ее в своей базе данных, если она не будет ее новой записью, и я бы ВСТАВЛЯЛ ее. Это некрасиво и не быстро, но анализ двоичного файла журнала тоже не очень хорош.
Я написал это, чтобы помочь понять проблему. часто сообщая это кому-то другому, помогает прояснить проблему, делая решение более очевидным. В этом случае у меня просто большая головная боль!
Ваши мысли будут очень благодарны.
Мои файлы журнала (двоичные журналы) тоже были моей первой мыслью. Если бы вы знали, как они поступали, вы содрогаетесь. Для каждой строки в журнале много записей, так как добавляются и изменяются фрагменты. Его просто ОГРОМНЫЙ! Пока я остановился на подходе Хэша. С помощью некоторой умной файловой памяти подкачки это довольно быстро.
Я не человек MySQL, поэтому это выходит из левого поля.
Но я думаю, что файлы журналов могут быть ответом.
К счастью, вам действительно нужно знать только 2 вещи из журнала.
Вам нужна запись /rowid, и вам нужна операция.
В большинстве БД, и я предполагаю, что в MySQL есть неявный столбец для каждой строки, такой как rowid или recordid, или что-то еще. Это внутренний номер строки, используемый базой данных. Это ваш "свободный" первичный ключ.
Затем вам понадобится операция. Важно отметить, что это вставка, обновление или удаление в строке.
Вы объединяете всю эту информацию в порядке времени, а затем выполняете ее.
Для каждой вставки/обновления вы выбираете строку из исходного БД и вставляете/обновляете эту строку в своей целевой БД. Если это удаление, то вы удаляете строку.
Вам не нужны значения полей, они просто не важны. Сделайте всю строку.
Вы, надеюсь, не должны "разбирать" двоичные файлы журналов, MySQL уже должен иметь подпрограммы для этого, вам просто нужно найти и выяснить, как их использовать (может быть, даже удобная утилита "dump log" вы можете использовать).
Это позволяет вам поддерживать систему довольно просто, и она должна зависеть только от вашей фактической активности в течение дня, а не от общего размера БД. Наконец, вы можете впоследствии оптимизировать его, сделав его "умнее". Например, возможно, они вставляют строку, затем обновляют ее, а затем удаляют. Вы бы знали, что можете просто игнорировать эту строку полностью в своем воспроизведении.
Очевидно, это требует немного тайных знаний, чтобы действительно читать файлы журналов, но остальное должно быть простым. Я хотел бы думать, что файлы журналов также имеют временную метку, поэтому вы можете знать, как работать с строками "с сегодняшнего дня" или любым диапазоном дат, который вы хотите.
Вы не можете использовать существующий код, который обращается к этой базе данных и адаптирует ее к вашим потребностям? Конечно, код должен быть ужасным, но может обрабатывать структуру базы данных для вас, нет? Вы могли бы надеяться сосредоточиться на том, чтобы ваша работа была сделана вместо того, чтобы играть с археологом.
вы можете использовать инструмент maatkit mk-table-sync для синхронизации промежуточной базы данных (в конце концов, ваша база данных очень мала). Это будет "дублировать беспорядок"
Затем вы можете написать что-то, что после синхронизации выполняет различные запросы для создания набора более важных таблиц, которые затем можно отчитывать.
Я предполагаю, что это можно сделать ежедневно, без проблем с производительностью.
Выполнение всего этого с другого сервера позволит избежать воздействия на исходную базу данных.
Единственная проблема, которую я вижу, - это если в некоторых таблицах нет первичных ключей.