Может, уже по ходу скажете, чем однострочный файл ~70Mb открыть и комфортно поредактировать?

Спасибо.

1. Использую LOAD DATA INFILE для очень быстрой загрузки данных во временную таблицу (CREATE TEMPORARY TABLE), потому что импортить файл в рабочую таблицу напрямую – опасно.

2. По необходимости переколбашиваю данные в нужных полях временной таблицы (она теперь является как бы отображением на CSV-файл) и из неё заливаю что мне надо уже в рабочую таблицу:

INSERT INTO `table` (`field1`, `field2`, `field3`)
SELECT FROM `temp_table` `csv_field2`, `csv_field4`, `csv_field5`

Получается всё равно в миллиорд раз быстрее, чем инсёртами из PHP заливать CSV-файл.

Есть ответ?

Например, как для CSV:
f1,f2,f3,f4,f5
1, 2, 3, 4 5, 6
добиться логики вставки:
insert into table {field1, field2, field3} values (2, 4, 5);

Теперь подробно.
Если бы я сам не пользовался предложенным в статье методом, я бы его и не советовал другим.

При импорте CSV средствами MySQL нет возможности контроля данных. PHP ведь не учавствует — вот и нечем проверить

Да, я старался убедить вас, что лучше не грузить большие объёмы данных PHP (неподходящий инструмент). Но никто не запрещает управлять загрузкой с помощью PHP (эдакий командный пункт), запуская нужные запросы, ниже я покажу как.

это прямая дорога к SQL-инъекциям и дефейсу

На лицо непонимание процесса загрузки: MySQL сервер сам отквочивает что надо. SQL-инъекции возможны как раз из-за использования PHP, с помощью которого нормальный запрос может быть исправлен на вредоносный. Другими словами, я не представляю, куда надо засунуть, скажем, “DROP DATABASE” в загружаемый файл, чтобы этот запрос выполнился, eval() тут нет.

Или я просто не знаю аналогов addslashes и htmlspecialchars в мускуле

QUOTE(), но он вряд ли пригодится.

Нет возможности подстраиваться под пользовательскую структуру

Кто ж хардкодит такие вещи… Сначала с помощью PHP fgetcsv() считываем первую строку (заголовок), показываем юзеру список полученных полей – пусть сам укажет, что куда заливать, типы данных, короче, что угодно. Когда такая инфа сохранена, то перемещение столбцов никак не повлияет на загрузку, потому что они запоминаются поимённо (а вообще часто приходится сталкиваться с переставленными столбцами?)
При использовании XML алгоритм будет похожий, с той разницей, что в этим случае уже целый геморрой получить список полей (XML ведь иерархический).

если организовать импорт того же CSV но построчно средствами PHP, то можно в скрипте реализовать опрос пользователя на типы каждого столбца

Связи никакой :] Почему если грузить построчно через PHP, то только тогда можно опрашивать пользователя? Для каждой загружаемой строки это делать? Пусть РНР только опрашивает пользователя о столбцах, а в загрузку пусть не лезет, этот болт не для него – для этого есть другой инструмент.

Для этого просто достаточно проверить наличие в тексте закрывающего корневого контейнера

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

Как только речь идет о внешних клиентах — им надо недоверять, данные проверять

Так вот, как это сделал я, не потеряв в безопасности и выиграв в скорости: загрузил всю инфу как есть во временную таблицу (CREATE TEMPORARY TABLE), и уже в ней выкусывал/форматировал/удалял что мне надо (PHP запускал нужные запросы). После этого уже чистые данные направлялись в рабочую таблицу.

Забудьте о скорости — нужна надежность

Как и все обобщения, это утверждение ложно.

Если мы спорим о файликах данных в 1-2 метра, то я могу согласиться даже с ручным написанием INSERT-запросов :] Я веду речь о файлах данных реального мира, отсчёт начиная с 40-50 Мб: я думаю, при вариантах “16 секунд” и “4 часа” пользователь будет меньше всего обеспокоен безопасностью, потому что во втором случае он может просто перестать пользоваться такой “безопасной”, но медленной системой. И что обидно – даже прогресс-бар по-человечески не сделаешь…

P.S.

не такие уже индусы глупые

Я русский, а у меня нет ни ушанки, ни медведя – так что я согласен ;]