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, проверяя, соответствуют ли хэш-коды. Если они этого не сделают, я бы прочитал эту запись и проверил, существует ли она в моей базе данных, если это произойдет, я бы обновил ее в своей базе данных, если она не будет ее новой записью, и я бы ВСТАВЛЯЛ ее. Это некрасиво и не быстро, но анализ двоичного файла журнала тоже не очень хорош.
Я написал это, чтобы помочь понять проблему. часто сообщая это кому-то другому, помогает прояснить проблему, делая решение более очевидным. В этом случае у меня просто большая головная боль!
Ваши мысли будут очень благодарны.
