Из dbf в MySQL и обратно. Производственная драма с прологом, но без эпилога.

На новой работе большая часть времени уходит на работу с базой данных.
База большая, хаотичная и в целом - внушает ужас. Увы, отнюдь не объёмами, но скорее качеством данных.

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

Хранится всё это Щастье в dbf. Разного рода вспомогательные базы, базочки, базюшески и просто обновления - в том же dbf.

Поскольку с dbf я дружу слабо, а с MySQL - средне, было принято решение - "загнать эту ... базу в мускуль, а там видно будет".
Как это ни смешно, решение оказалось правильным. С другой стороны, есть подозрение, что правильным было бы любое решение, потому что один из принятых в этой конторе методов обработки информации заключался в "распечатать всё, а потом силами нескольких человек найти нужное в распечатках, а потом вручную вбить обратно".

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

aptitude search навёл меня на утилиту dbf2mysql

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

У утилиты этой есть один, но существенный на мой взгляд, недостаток.
Автор её и слыхом не слыхивал о существовании кодировок, отличных от latin1.
В результате имеем таблицу в кодировке latin1, набитую данными в кодировке CP866.

Но нас таким не напугаешь. Возможно кто-то применит секретное заклинание alter table, сменит тип данных с текстового на blob, выправит кодировку, а потом сменит тип данных обратно, но это не мой путь. Этих самых полей у меня - неисчислимое множество (ну вру. Исчислимое, что уж там. Но всё равно - много).

Выручает старый-добрый mysqldump с принудительным выставлением кодировки в latin1.

Обрабатываем полученный файл напильником iconv'ом, перегоняя из CP866 в юникод, меняем в нём кодировку с latin1 на utf8, drop-аем таблицу, загоняем дамп обратно в мускуль - et voila!

Дабы работать было удобнее, добавляю отдельное поле типа int, заполняю его автоинкрементом и индексирую по нему. Иначе - совсем грустно. Но это уже сугубо моя локальная специфика.

Самое интересное начинается, когда приходит время загнать данные из MySQL обратно в dbf. Вот тут уже - чистое шаманство.
Вышеупомянутая утилита dbf2mysql имеет и оборотную сторону mysql2dbf. И даже вроде как работает, но...
Но о кодировках, отличных от latin1 можно забыть.

Но настоящего джедая не напугать такими мелочами.
Берём, делаем выборку из MySQL, посредством INTO OUTFILE формируем csv, открываем готовую dbf-ку с нужной структурой редактором dbf от pssoft.ru (спасибо автору), удаляем все данные и импортируем туда данные из csv. Одно уточнение - данные в csv должны быть в CP1251, но это такие мелочи...

От счастливого финала нас отделяет только N-ное количество щелчков мышью. Каждое поле dbf-а нужно сопоставить полю csv-шки. Автоматизировать - никак. У меня таких полей - 70.

Клик-клик-клик...
Клик-клик-клик...
Клик-клик-клик...

ДААА! Экспорт в dbf и вожделенный файлик на диске, будь он неладен.

К чему всё это? К тому, что если кто знает способ лучше - я просто изнемогаю от желания его узнать. А пока тихо радуюсь, что результаты обработки в 90% случаев нужны не в dbf, а в xls, получить который из csv - дело пары минут.

Занавес.