Нужно перенести данные из текстового файла в Mysql

Tranquil

Новичок
PHP:
<?php
$tmp = "tmp/price.txt";
if (file_exists($tmp)){
$lines = file ($tmp);
$n=0;
foreach ($lines as $line_num => $line) {
         $lineex[$n] = explode(chr(9),$line);
         $n++;
}
$m=count($lineex);
}
if (!empty($textimp["tmp_name"])){
   move_uploaded_file($textimp["tmp_name"], $tmp) or die ("Файл не копируется!");
}
$dob=0;
for ($n=0;$n<$m;$n++){
       $wart = $lineex[$n][0];
       $wname = preg_replace("[\"|\']","&quot;",$lineex[$n][1]);
       $wpr = preg_replace("[\"|\']","",$lineex[$n][2]);
       $wskl = $lineex[$n][3];
       if ($wart!="" & ctype_digit($wart)){
          $sartik = substr($wart, -4);
          $result = mysqlConnect("select id from catalog where artikul='$sartik' limit 1");
          $row=0;
          do {$row++;}
          while ($workid[$row]= mysql_fetch_array($result,MYSQL_ASSOC));
                if ($workid[1]==""){
                $nextid = NId('catalog','id');
                 mysqlConnect ("insert into catalog(id,artikul,sk) values('$nextid','$sartik','$wskl')");
                 mysqlConnect ("insert into price(num,gr1) values('$nextid','$wpr')");
                 mysqlConnect ("insert into catalogru(num,name) values('$nextid','$wname')");
                 $dob++;
                 }
       }
}
$ti = NId('catalog')-1;
echo "Добавлено - $dob позиций! В каталоге - $ti";
?>

А у меня вот так. Замечания?
 
код странный.
название функции mysqlConnect меня убивает.
наличие функции NId наводит на нехорошие мысли
 
А я бы так :))

в phpmyafmin есть вставка текстового файла в таблицу, с соблюдением соответствия данных и типов полей, и без всяких странных логик приведенного тобою скрипта
 
У меня идет вставка базы из 60-метрового файлика на 400000 строк. Ну, во-первых при аплоде такого файла в ИЕ комп падает в синий экран. А во-вторых по одной строке или все сразу вставлять нельзя. Строк по 5000 за раз в цикле, как счетчик превышает порог - слив считанных строк в базу. Причем либо
LOCK TABLES, DELETE, грохнуть индекс, INSERT, добавить индекс, UNLOCK
либо
TRUNCATE, INSERT DELAYED
2500 запросов/сек выходит
 
DiMA
sorry, уточню для себя - а "грохнуть индекс / добавить индекс" имеет большой смысл в этом случае?
 
конечно, быстрее создать индекс разом, чем постепенно, при постепенном наполнении таблицы
 
что есть "создается"? при LOCK TABLES он не должен меняться на диске.. а дальше уж от реализации работы с ними в mysql должно зависеть... в теории - при добавлении в худшем случае время будет тратиться на выделение очередного куска памяти, что не должно быть дольше, чем однократное перечитывание инфы с диска после создания индекса.. а на практике?
 
<что есть "создается"?> - ты о чем ?

если ты хочешь поспорить, что будет быстрее, наполнить таблицу "LOCK TABLES, DELETE, грохнуть индекс, INSERT, добавить индекс, UNLOCK" или без операций с индексом - так проведи исследование и результаты в студию! Все с интересом ждут. А пока я буду делать как считаю правильным и читал в учебниках очень давно.
 
DiMA
А пока я буду делать как считаю правильным и читал в учебниках очень давно.
точно - "я буду советовать, а исследование проводи сам".. интересный подход
и будет как в сказке про репку - DiMA за книжку, Tranquil за DiMA...

http://www.pastebin.ru/2958

-~{}~ 27.05.06 15:45:

php5.1.4 / MySQL 5.0.18-nt

------------- без индексов и блокировок -----------
UNLOCK TRUNCATE DROPKEYS
Time of test #1 is 37.118468
-------------------------------------------------------------

------------- с индексом, без блокировки ----------
UNLOCK TRUNCATE ADDKEYS
add primary time : 0.005911
add index time : 0.004525

Time of test #2 is 36.933077
-------------------------------------------------------------

------------ c блокировкой и удалением индекса ------
UNLOCK TRUNCATE DROPKEYS LOCK UNLOCK ADDKEYS
add primary time : 23.992994
add index time : 30.872197

Time of test #3 is 88.460082
-------------------------------------------------------------------

-------------- c блокировкой и без удаления индекса ----
UNLOCK TRUNCATE DROPKEYS ADDKEYS
add primary time : 0.004214
add index time : 0.004167
LOCK UNLOCK
Time of test #4 is 36.695762
-----------------------------------------------------------------------

[sql]
CREATE TABLE `ind` (
`id` int(10) unsigned NOT NULL,
`intvar` int(11) NOT NULL,
`textvar` text NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=cp1251;
[/sql]
 
ладно, ладно, я тоже протестирую в понедельник свой заливальщик 400 тыщ. таблички, хотя вынужден заливать в живую таблицу без лока (TRUNCATE + INSERT DELAYED)

и у меня примари кей - varchar(14), чисел нет

Ряды 433,711
Длина ряда &#248; 37
Размер ряда &#248; 61 Bytes
Данные 15,787 KB
Индекс 9,971 KB
Всего 25,758 KB

INSERT DELAYED 164.9868 сек.

LOCK + INSERT, с существующим индексом 174.6899 сек.

LOCK + INSERT, без индекса 154.7787 сек. и 18 секунд на новый индекс, итого 172 сек.

Профессора кажется идут отдыхать. Мало того, что в силу нужности данных я не могу их блокировать и юзаю INSERT DELAYED, даже фишка с удалением индекса дает 2 секунды преимущества =) Можно еще придумать способ заливать в новую таблицу, удалять старую, и переименовывать новую.
 
на Длина ряда &#248; 37 "даже фишка с удалением индекса дает 2 секунды преимущества" (а то и больше), на Ряды 100,000 Длина ряда &#248; 3,008 Размер ряда &#248; 3,033 Bytes такая фишка "немножко" тормозит собстна
 
И что, профессор? У тебя небось число в примари кей. У меня же сложнее - строка, вернее 2 поля varchar(14) + char(1). 430 тыщ записей, тоже не мало. База всех запчастей некоторых производителей с названиями и ценой. У тебя индекс по числам должен в разы быстрее построиться, а не у меня. Видимо, просто сервер тормозной =)
 
У тебя небось число в примари кей. У меня же сложнее
я не понял - автор вопроса - ваш коллега и у вас одна на двоих с ним база на одном и том же нетормозном сервере и у обоих ключи на varchar(14)+char(1) с размером ряда до 100байт... ? или вы думаете, что я вам доказываю, что ваш суперзаливщик, заливающий аж 430тыщ!!! записей и умеющий создавать суперсложный индекс по варчар+чар написан неправильно? он явно написан идеально - ведь аж на 2 секунды чего-то там обгоняет

на самом же деле мне интересно - вы советуете убивать ключ перед вставкой данных. у меня на моем тормозном сервере (который, если и тормозит, то на всем одинаково) создание ключа по времени равно вставке всех данных с уже имеющимся ключем.. версия mysql/php указана, код есть, примерные вставляемые данные известны - как ваша документация конца 90ых и пронафталиненная книжка объясняют сей печальный факт?

У тебя индекс по числам должен в разы быстрее построиться
да спору нет - int по 300меговой таблице должен работать в разы быстрее, чем варчар по 15меговой
 
я понял, что ты ничего не понял
к автору я топика отношения не имею
выше я написал, что лучше убить индекс, залить базу, восстановить индекс, и привел показательный пример из жизни
а че ты тут выступаешь и никак не уймешься - не понятно
 
выше я написал, что лучше создать индекс и залочить базу и привел пример.. а че ты тут про свой заливщик и свои индексы понаписал - непонятно
 
Мне казалось, даже тупому будет ясно, почему индекс лучше создать разом: чтобы не вылезали проблемы дефрагментации файла индекса, затраты на его оптимизацию, затраты на на поиск вставки новых элементов к каждому запросу и т.д. Провести один раз сортировку проще и быстрее, чем пересортировывать индекс постоянно. Вроде элементарно. Но как видно не для всех.
 
мне казалось даже тупому будет ясно, что индекс не должен "создаваться" (вот ваше, дима, объяснение слова "создается" я в свое время и спрашивал - см.выше) на диске при залоченной таблице (у мну так в мануале по mysql написано, а у вас в книжке по другому? или страницу моль скушала?), а если включить мозги, то станет ясно, что работать с индексом в оперативке не должна быть в разы дольше, чем перечитать большую таблицу с диска при создании индекса разом
 
Сверху