Задача стоит следующим образом: есть около сотни *.csv-файлов (с разной структурой) общим объемом порядка 250 тыс. строк. Необходимо организовать поиск по ним. На данный момент если поиск осуществляется по одному слову, то он занимает в среднем порядка 3-7 сек, иногда доходит до 15 (в зависимости от загруженности сервера). Хотя бывают случаи, когда на поиск уходит 30-60 сек (При очень больших тормозах на серваке. Такое бывает достаточно редко, но пользователям же не объяснишь все эти нюансы, когда они заходят на сайт).
Как сократить время, затрачиваемое на поиск?

Буду признателен за любой совет или ссылку.

А в ответ тишина...

Неужели никто не работал с большим объемом данных и не пытался сократить время на поиск?
Меня интересуют любые нюансы, позволяющие хоть мало-мальски ускорить процесс поиска ключевых слов в текстовом файле. Какие функции и приемы стоит использовать, а какие нет?
Хоть что-нибудь...

Usya можно попробавать многопоточность, чтобы одновременно несколько файлов просматривалось.

Спасибо
Надо попробовать. Хотя, честно говоря, никогда не имел с этим дело. Просто не доводилось
Придется разбираться
Получится или нет - напишу...

Я бы предложил сделать систему индексации. Запускать индексирование файлов по cron-у раз в сутки или раз в N часов (зависит от того, насколько часто обновляются файлы) с невысоким приоритетом, что бы это не влияло на работу сервера в целом.
Можно сделать "инкрементальное" индексирование, если существующие файлы не изменяются, а к ним только добовляются новые.
Поиск делать уже по индексу, который хранить, к примеру, в BercklyDB файлах (.dbm). Как именно индексировать решай сам, есть масса вариантов.
К примеру таблицы типа:

Files
---------
id_file
file_name (path)


Words
---------
id_word
word

Word2File
---------
id_word
id_file

Надеюсь мысль понятна, удачи!

Мысля понятна. За совет спасибо!
Однако мне кажется, что здесь проблем не меньше…

Я выше писал, что файлы имеют разную структуру, поэтому под один шаблон их не подгонишь. Если быть конкретнее, то в *.csv-файлах хранятся таблицы с разным количеством столбцов (от 2-х до 14-и). И если можно их загнать в базу, то только в одно поле. Соответственно теряются почти все преимущества работы с БД.
Кроме того, в исходных таблицах в *.csv-файлах есть подзаголовки, которые придется выносить в отдельное поле, хотя это не принципиально.
Таким образом, окончательно может быть выделено всего три поля - имя файла(и соответствующая ему фирма)+шапка таблицы, подзаголовки и все остальное. При поиске будут учитываться только два последних.

Кроме того, желательно, чтобы информация после поиска выдавалась не беспорядочно, а последовательно от одного файла (фирмы) к другому, от одного подзаголовка к др. Т.е. потом придется выполнить сортировку по первым двум полям. А если кто-то решит поприкалываться либо оказать медвежью услугу и введет всего одну букву, например, 'а', то все 250 тыс. записей должны быть отсортированы (честно говоря, не знаю, сколько времени это займет и сколько памяти на серваке это потребует). Хотя, возможно, это решаемо сопоставлением с соответствующим проиндексированным по первым двум полям файлом либо введением дополнительного поля – порядкового номера записи с последующей сортировкой найденных записей по этому полю.

И последнее, на данный момент у меня только 250 тыс. записей, но это не предел. Надеюсь, что будет больше как минимум раза в два. Кроме того, здесь приходится учитывать ограничения хостинга на память и загрузку процессора. Честно говоря, пока с этой стороной вопроса не сталкивался, но как бы там не оказалось подводного камня.

Возможно, некоторые доводы абсурдны, потому что с базами данных я относительно мало работал, но думаю, что связываться с БД в данном случае не имеет смысла.

Доводы не абсурдны, но я предлагал тебе не перевод всех файлов в базу, а только индексы хранить в базе. То есть на примере локального поисковика в тех же Форточках ХП
То есть ты с определенной периодичностью запускаешь скрипт который строит индексы по твоим файлам, а потом используешь эти индексы для поиска.
К примеру, у тебя есть директория с документацией, в ней хранятся доки в txt формате (plain text). Для того что бы найти нужную доку, скажем по Perl у тебя есть два варианта. Первый - открывать каждый файл, искать в нем слово Perl, если есть добавлять в массив с документами отвечающими запросу, нет - искать дальше. Если я правильно понял, то так у тебя сейчас и работает.
Второй путь. Индексируешь файлы. Т.е. открываешь файл и строишь по нему таблицу вида (самый простой вариант) слово - имя файла. Естественно что ты можешь не включать слова типа "а", "и", "!" и т.п. Затем открываешь следующий файл и добавляешь в табличку. В итоге имеешь таблицу вида:

perl - perlfaq.txt
perl - perlref.txt
perl - regexp.txt
regular - regexp.txt
...

и так далее.
Тот пример хранения который я привл раньше лучше, поскольку нет избыточности данных. То есть это будет выглядеть так:

Worlds
1 - perl
2 - regular
3 - linux
...
---------------------
Files
1 - perlfaq.txt
2 - perlref.txt
3 - regexp.txt
...
--------------------
W2F
1 - 1
1 - 2
1 - 3
2 - 3
...

Соответственно, на запрос perl мы получим ответ что это слово встречается в 3-х документах. Есть масса алгоритмов индексирования, так что если пороешь в этом направлении наверняка найдешь то что надо. Хочу заметить что на этом принципе работают поисковые системы, а у них, как ты понимаешь, несколько больше чем 250 000 записей ;)

Цитата

Первый - открывать каждый файл, искать в нем слово Perl, если есть добавлять в массив с документами, отвечающими запросу, нет - искать дальше.

Помимо имен файлов, должны выдаваться все строки (записи), где встречается данное слово (слова). Я мельком упомянул об этом, но не догадался на этом акцентировать внимание , хотя это принципиально. Возможно часть идей просто бы отпала...

Цитата

В итоге имеешь таблицу вида: ...

А если пользователь вводит только часть слова? Для каталога прайс-листов как быть при такой индексации, если пользователь не помнит полностью номер модели искомого товара, а только последние четыре цифры из пяти? Кроме того, в исходных файлах может быть куча информации, по которой искать точно не будут (например, столбец цен), но в индексные файлы загонять придется, чтобы не делать дополнительных наворотов на то, что индексировать, а что нет для каждого из файлов с последующим контролем от незапланированных изменений.

Цитата

Хочу заметить что на этом принципе работают поисковые системы, а у них, как ты понимаешь, несколько больше чем 250 000 записей ;)

Принцип такой, но не все там так просто

Цитата(Usya @ 20.8.2005, 20:10)

Я выше писал, что файлы имеют разную структуру, поэтому под один шаблон их не подгонишь. Если быть конкретнее, то в *.csv-файлах хранятся таблицы с разным количеством столбцов (от 2-х до 14-и). И если можно их загнать в базу, то только в одно поле. Соответственно теряются почти все преимущества работы с БД.

Можно почитать о принципах построения БД. И идея запихнуть все в БД перестанет быть настолько абсурдной.
На вскидку - создай таблицу примерно следующей структуры

Код

id - уникальный номер записи, автоинкремент, к примеру.. value - значение поля ref - ссылка на следующее поле в этом наборе данных

Цитата

А если кто-то решит поприкалываться либо оказать медвежью услугу и введет всего одну букву, например, 'а', то  все 250 тыс. записей должны быть отсортированы (честно говоря, не знаю, сколько времени это займет и сколько памяти на  серваке это потребует).

Не забывать о здравом смысле Оцени твой набор данных, и реши какой минимальной длинны может быть поисковое слово. Почему то кажется , что не меньше трех букв.

Цитата

Возможно, некоторые доводы абсурдны, потому что с базами данных я относительно мало работал, но думаю, что связываться с БД в данном случае не имеет смысла.

Я бы все же ихал в БД. Причем БД с кешеривоанием запросов.

Guest за советы спасибо, но есть несколько но!!!

Цитата

Можно почитать о принципах построения БД.

Насколько я знаю, БД нужны, прежде всего, для устранения избыточности информации. За счет этого можно значительно сократить объем хранимой информации и соответственно ускорить поиск. Плюс дополнительные ускорение, связанное с индексацией. А здесь избыточность изначально практически отсутствует.

Цитата

На вскидку - создай таблицу примерно следующей структуры

Если и придется создавать таблицу, то скорее всего со следующей структурой; id - уникальный номер записи, firma - адрес фирмы+шапка таблицы, pdz - название подзаголовков (категории в прайсах), value - сами записи (позиции прайс-листов), ref - ссылка на следующее поле в этом наборе данных - ??? - возможно и надо - надо подумать.

Цитата

Не забывать о здравом смысле... Почему то кажется , что не меньше трех букв.

Минимум два, например, аббревиатура ноутбука (NB), фирмы (HP) и т.д...

Цитата

Я бы все же ихал в БД. Причем БД с кешеривоанием запросов.

А здесь куча вопросов:
1) Стоит ли шкурка выделки? Сильно обрезать исходные данные при переходе к БД не удастся (уже написал почему)... Единственное, в чем принципиальный плюс при переходе к БД, возможно в заточенной процедуре поиска. Но на сколько (или во сколько) это сократит время на поиск в моем случае? Если б знать порядок. Пока что, разбираюсь в распараллеливании процессов в Perl-e. Думую, что из этого можно кое-что полезное выцепить.
2) Какой объем памяти потребуется при использовании БД и какова будет загрузка проца на серваке при простом запросе и при индексации (которую придется делать по хорошему каждые час два по мере обновления прайсов)? На данный момент у меня порядка 20-25 метров инфы, но это не предел. Надеюсь, что будет как минимум раза в два поболее. Как бы ребята из отдела хостинга не попросили пересесть на что-нибудь более легкое, когда уже все будет работать. Это самый главный минус в этой задаче не в пользу БД!!!

Usya как ты работаешь с csv-файлами и как ты производишь поиск?

если я сделал правильную догадку по этому поводу, то .

Цитата(Usya @ 22.8.2005, 13:58)

Guest  за советы спасибо, но есть несколько но!!! Цитата Можно почитать о принципах построения БД. Насколько я знаю, БД нужны, прежде всего, для устранения избыточности информации. За счет этого можно значительно сократить объем хранимой информации и соответственно ускорить поиск. Плюс дополнительные ускорение, связанное с индексацией. А здесь избыточность изначально практически отсутствует.

БД прежде всего предназначены для _эффективной_ работы с данными. А избыточность информации - эт дело такое... При 1НФ может быть, скорей всего обязана быть а 4НФ или 5НФ таки да избыточности быть не должно. Но поиск ускорется не потому что инфы мало, а потому что есть заточенный для этого энджайн

Цитата

Цитата На вскидку - создай таблицу примерно следующей структуры Если и придется создавать таблицу, то скорее всего со следующей структурой;

Цитата

id - уникальный номер записи, firma - адрес фирмы+шапка таблицы,

Это ты в каждой записи собираешься тиражировать реквизиты фирмы!?

Цитата

pdz - название подзаголовков (категории в прайсах),

Продолжение

Это ты предлагаешь такую структуру, что бы показать насколько избыточна будет твоя инфа, если ее поместить в БД?;)

Цитата

value - сами записи (позиции прайс-листов),

Чуть подробнее об этом поле. Какая инфа будет лежать в нем?

Цитата

Цитата Не забывать о здравом смысле... Почему то кажется , что не меньше трех букв. Минимум два, например, аббревиатура ноутбука (NB), фирмы (HP) и т.д...

Я ж говорю, незабывать о здравом смысле)) Название фимы, и сокращенное наименование изделия - это не то по чем ищут пользователи. Это те пареметры, по которым ты предоставляешь пользователям ограничить круг поиска. К примеру выпадающий список
вид компьютера - Ноутбуук - десктоп - сервер - и тд
Фирма призводитель ИБМ - САН - Ньюлет - и тд.
Идея ясна?

Цитата

Цитата Я бы все же ихал в БД. Причем БД с кешеривоанием запросов. А здесь куча вопросов: 1) Стоит ли шкурка выделки? Сильно обрезать исходные данные при переходе к БД не удастся (уже написал почему)...

Я не совсем понял, где я предлогал "резать" данные?

Цитата

Единственное, в чем принципиальный плюс при переходе к БД, возможно в заточенной процедуре поиска. Но на сколько (или во сколько) это сократит время на поиск в моем случае? Если б знать порядок. Пока что, разбираюсь в распараллеливании процессов в Perl-e. Думую, что из этого можно кое-что полезное выцепить. 2) Какой объем памяти потребуется при использовании БД и какова будет загрузка проца на серваке при простом запросе и при индексации (которую придется делать по хорошему каждые час два по мере обновления прайсов)? На данный момент у меня порядка 20-25 метров инфы, но это не предел. Надеюсь, что будет как минимум раза в два поболее. Как бы ребята из отдела хостинга не попросили пересесть на что-нибудь более легкое, когда уже все будет работать. Это самый главный минус в этой задаче не в пользу БД!!!

А эт все от тебя зависит
Ну а если серезно, то сейчас глянул на БД одного из своих сайов 117 МБ. 76 000 записей. Поиск по текстовым полям практически не влияет на скорость загрузки страницы.

Только здается мне тебе не поиск нужен, а хорошая структура прайс листа. На мой вкус - лучше 4 раза кликнуть мышей, чем набрать некое слово и получить 10 ссылок...

Блииииииииин!!! Щас набрал ответ и умудрился его убить

Чтоб не ходить вокруг да около, постараюсь поточнее сформулировать задачу: с ряда сайтов закачиваются прайс-листы и конвертируются в *.csv-формат для дальнейшей обработки. Поисковик при запросе должен выдавать записи последовательно от прайса к прайсу, от позиции к позиции сверху вниз.

Кроме того, т.к. прайсы зачастую делают, кто как хочет со своими обозначениями и сокращениями (например, вместо картридж могут быть - к-дж, к/дж, фотокондуктор и т.д., не говоря уже случайной замене русских букв на англ и наоборот), не хочу делать выпадающий список - слишком много геморра. Тем более что в запросе может быть часть номера модели устройства. А на счет здравого смысла - минимальной длины запроса - вполне может быть аббревиатура фирмы из двух букв (чтоб не перебирать все возможные сокращения в названии товара).

Цитата

value - сами записи (позиции прайс-листов)...Чуть подробнее об этом поле. Какая инфа будет лежать в нем?

Обычная рабочая позиция прайса, например, - Валик структурн 140 желт ОБ;25;60.00.

Цитата

Только здается мне тебе не поиск нужен, а хорошая структура прайс листа.

Как писал выше, структуру исходных прайсов изменить не могу. Приходится иметь дело с тем, что есть. А в БД придется делать таблицы с названиями фирм, реквизитами ...; с подзаголовками в прайсах и сводную с полным перечнем всех позиций прайс-листов.

Цитата

Я не совсем понял, где я предлогал "резать" данные?

Я имел ввиду урезать избыточность. Об этом я писал.

Цитата

Ну а если серезно, то сейчас глянул на БД одного из своих сайов 117 МБ. 76 000 записей. Поиск по текстовым полям практически не влияет на скорость загрузки страницы.

Если скорость закачки страницы будет мала, а страница - тяжелая, то так оно и будет Кроме того тот же эффект будет если вся БД будет забита в основном картинками или т.п. А если серьезно, то на скорость поиска в БД влияет много факторов, в том числе по какому полю идет поиск и сколько в этом поле инфы, остальное же будет в качестве довеска при выводе. Кстати, можешь немного описать свою базу или черкануть ссылку на сайт, чтоб сопоставить объем работы при поиске? И еще вопрос, сколько у тебя уходит времени на индексацию и каков может быть объем памяти (по твоим оценкам), требуемый для индексации и запроса в твоем случае? И тоже самое для моего случая (по прикидкам) из расчета на имеющиеся 20-25 метров текста и 250000 записей, а также для 50 метров и 500000 записей (то, на что я ориентируюсь)? Это меня, как я писал, и беспокоит...

Это сообщение отредактировал(а) Usya - 22.8.2005, 23:35

Usya

Цитата(sharq @ 22.8.2005, 16:48)

как ты работаешь с csv-файлами

спасибо за ответ...

В общем для работы с csv-файлами существует очень хороший модуль DBD::CSV - драйвер БД CSV для DBI-интерфейса.

Читаем документацию и работаем с csv (поиск и др.) с помощью SQL-запросов.

sharq , извини, проглядел случайно, а ты сразу язвить начал!!!

Спасибо за совет

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

Это сообщение отредактировал(а) Usya - 22.8.2005, 23:48

sharq

Сегодня ночью лазил на cpan.
Все конечно хорошо, но для этой задачи данный модуль не подойдет. Насколько я разобрался, для работы с данным модулем нужны "нормальные" таблицы в *.csv-файлах. Но, сам понимаешь, при конвертации прайса из *.xls в *.csv-формат это не реально, т.к. помимо таблиц в *.csv-файлах может быть куча всякой ерунды. Кроме того, как я писал, при поиске необходимо учитывать подзаголовки. Так, например, если в подзаголовке написаны мониторы, а в текущих позициях только модели, то при запросе “мониторы” – должны быть выведены все модели… А при работе в лоб с этим модулем, такое не покатит. Придется извращаться…

Хотя, честно говоря, полезная штучка. Думаю, что пригодится мне правда в другом проекте

Usya

Цитата(Usya @ 23.8.2005, 14:01)

Кроме того, как я писал, при поиске необходимо учитывать подзаголовки

А что тебе мешает учитывать подзаголовки?

Ты вручную конвертируешь xls -> csv или есть какой механизм, или пользователи сами конвертируют и закачивают на сервер?
Добавлено @ 16:14

Цитата

а ты сразу язвить начал!!!

sharq

Цитата

Ты вручную конвертируешь xls -> csv или есть какой механизм, или пользователи сами конвертируют и закачивают на сервер?

Они в автоматическом режиме закачиваются на сервак, там же и конвертируются с помощью Spreadsheet::ParseExcel, при этом проходят небольшую предварительную обработку для выделения шапок таблиц, а также подзаголовков и всякой ерунды насколько это возможно. Полностью разложить прайс по полочкам без просмотра человеком, сам понимаешь, в принципе не возможно. Взять, например, многоярусные подзаголовки с дальнейшим дроблением внутри...

Цитата

А что тебе мешает учитывать подзаголовки?

Я поверхностно ознакомился с DBD::CSV, но насколько понял, он работает с реляционными таблицами. При этом, чтобы в *.csv-файле была такая таблица, надо искусственно ввести еще одно поле с названиями подзаголовков или соответствующими индексами из отдельно созданной таблицы подзаголовков, лежащей в другом файле. В первом случае исходный *.csv-файл будет раздуваться (причем может значительно). Во втором - придется совместно искать и там и там. При этом скорее всего данный модуль будет бессилен для совместного поиска - нужно будет как-то комбинировать самому. Хотя, в принципе, здесь уже попахивает базами данных

Или я что-то не понял?

Usya ты сам выбрал формат csv или постановка задачи такая?

Цитата(Usya @ 23.8.2005, 22:04)

Я поверхностно ознакомился с DBD::CSV, но насколько понял, он работает с реляционными таблицами

Ты когда-нибудь с БД работал, используя модуль DBI и соответствующий драйвер бд.

Цитата(Usya @ 23.8.2005, 22:04)

реляционными таблицами

масло масленное получилось...

Цитата(Usya @ 23.8.2005, 22:04)

Во втором - придется совместно искать и там и там

ты знаешь, что такое связи и нормализация БД?
если нет, то почитай где-нибудь проектирование баз данных.

Единственное что я не понимаю - это проблемы, почему ты не можешь работать с csv-файлами как с таблицами бд, тем более очень удобный интерфейс есть DBI.

Ладно, давай передем от слов к делу - так чтобы с конкретными примерами, с конкретными вопросами и проблемами. Только от начала и до конца.

Это, конечно, если ты хочешь в своей проблеме разобраться.

sharq

Формат csv я выбрал сам, чтобы сократить время на поиск. Если каждый раз при поиске загружать Spreadsheet::ParseExcel, то можно время на поиск будет исчисляться минутами (а то и десятками минут).

С БД я работал, правда не слишком плотно - полугодовой курс в институте+пару месяцев сам изучал SQL Server. Так что с азами, в принципе, знаком.

Цитата

реляционными таблицами...   масло масленное получилось...

Данную фразу употребил, чтобы подчеркнуть, что структура прайс-листа хоть и имеет вид таблицы, но не реляционной. Здесь то зачем было придираться?

Цитата

Ладно, давай перейдем от слов к делу

Так я и сам этого хочу. На данный момент есть два варианта:
1. Работать с файлами, как с обычной текстовой информацией, и соответственно оптимизировать такой код, чем я до сих пор и занимался. Кстати, спасибо за идею многопоточности. Правда здесь, скорее всего, подойдет распараллеливание процессов. С типовыми примерами уже разобрался, осталось попробовать в данной задаче.
2. Работать с БД. Тогда не вижу смысла работать с каждым из файлов в отдельности. Придется все сливать, как уже писал в три таблицы – таблицу с названиями фирм, их реквизитами и шапками таблиц прайсов, таблицу подзаголовков и сводную таблицу с полным перечнем всех записей. (Если есть другой вариант, напиши какой). Посмотри, если не трудно, конец 10-го сообщ. Если работал с БД, сколько (по твоим прикидкам) будет уходить времени на индексацию и какой объем памяти может потребоваться для индексации и запроса из расчета на имеющиеся 20-25 метров текста и 250000 записей, а также для 50 метров и 500000 записей (то, на что ориентируюсь)? Это меня, как я писал, и беспокоит...

P/s
Кроме того, честно говоря, не думаю что индексация значительно сократит время на поиск, т.к. в половине прайсов либо в первом, либо втором столбце стоит порядковый номер товара, по которому точно никто искать не будут... А дополнительно указывать по какой колонке в каждом прайсе индексировать - слишком много геморра, тем более, что структура прайсов порой может меняться.

Это сообщение отредактировал(а) Usya - 24.8.2005, 08:27

Я не знаю что тебе посоветует sharq, но лично я бы остановился на БД. Думаю, вся эта канитель будет удобнее, проще и быстрее.

Это сообщение отредактировал(а) korob2001 - 24.8.2005, 09:26

korob2001, спасибо за совет, но что бы ты ответил на следующий вопрос:

Цитата

Если работал с БД, сколько (по твоим прикидкам) будет уходить времени на индексацию и какой объем памяти может потребоваться для индексации и запроса из расчета на имеющиеся 20-25 метров текста и 250000 записей, а также для 50 метров и 500000 записей (то, на что ориентируюсь)? Это меня, как я писал, и беспокоит...

Сервак не мой и я, сам понимаешь, на правах юзера в отношении ресурсов.

P/s
О структуре БД написано выше.

Ну я думаю нет смысла индексировать всё, токлько то, что нужно. Размерность зависит от того, какие типы полей нужно индексировать. Так же совсем не обязательно индексировать всё поле. Вобщем сначала нужно создать таблицы, что бы явно видеть, как жить дальше.
Приведи хотя бы одну запись полностью, от неё и будем отталкиваться. Можешь изменить ту инфу, которую не хочешь выставлять на показ, но так, что бы не нарушить структуру.

Usya я также тебе советую остановится на БД, именно для твоей задачи и твоих объемов это будет лучше, чем использование файлов.

Цитата(Usya @ 24.8.2005, 08:24)

Придется все сливать, как уже писал в три таблицы – таблицу с названиями фирм, их реквизитами и шапками таблиц прайсов, таблицу подзаголовков и сводную таблицу с полным перечнем всех записей

Пока не вижу необходимости, но всякое бывает...

Поэтому чего гадать, нужны примеры: приведи пару csv-файлов (разной структуры) и там будет видно что и как.

Usya не думай пока об объемах, вот будет у тебя второй вариант рабочий, тогда и будешь его сравнивать с первым и делать соотв. выводы.

Еще есть вариант работать с xml, но это пока просто вариант.

P.S. о каких придирках ты говоришь, я просто советую как лучше.

korob2001

Простейший пример без нормализации утрированно может выглядеть следующим образом (в полном объеме слишком много будет):

Фима + реквизиты + шапка таблицы / Подзаголовок / Позиция прайса
Вектор – г. Бобяково…- наименование::цена / Мониторы / Samsung 577;3031
Вектор – г. Бобяково…- наименование::цена / Мониторы / Samsung 757;4031
ДИО – г. Лепяги…- №::наименование::код::р-цена / --- / 235;Масло подс;35223;37р.

По большому счету не менее 95% информации исходного прайс-листа будет заключено в последнем поле (от 2-х до 14 колонок исходного п/л). При нормализации первое и второе поля отойдут в отдельные таблицы. И если индексировать, то по “подзаголовкам” (это совсем мелочь) и по “позициям прайса” (а это, как я уже говорил 95% от общего объема). Причем поиск, в большей степени, будет как раз по третьему полю. При запросе "монитор 57" должно быть выдано следующее:
Вектор
Наименование цена
Мониторы
Samsung 577 3031
Samsung 757 4031

sharq

Цитата

Поэтому чего гадать, нужны примеры: приведи пару csv-файлов (разной структуры).

Если нужно, выложу, но может быть будет достаточно следующего аналога - если взять любой прайс из какой-либо компьютерной фирмы и конвертнуть в csv-формат, получим материал для работы.

Цитата

Usya не думай пока об объемах, вот будет у тебя второй вариант рабочий, тогда и будешь его сравнивать с первым и делать соотв. выводы.

Честно говоря, когда я писал свой вопрос, то думал о том, как оптимизировать поиск по текстовым файлам. Кое-какие нюансы методом проб выявил, думал еще пополнить запас для дальнейших экспериментов.
А в отношение БД просто много минусов:
1)В моем тарифном плане м/б только одна БД, а я еще думал форум поставить (иначе придется переходить на другой т/план);
2)Мне придется устанавливать соответствующий софт у себя на компе и разбираться в этом (хорошо, если пойдет все сразу, хотя это не самое главное).
3)Будет досадно, если после всего геморра (перехода с рабочего варианта на БД) БД окажутся слишком прожорливыми в отношении ресурсов (а мне так никто и не ответил на счет этого) и меня попросят от них отказаться или просто в связи с тем, что нормализовать данные толком не удастся выигрыш по времени окажется раза в два-три (этого, в принципе, как писал выше можно частично добиться путем распараллеливания процесса ).

Хотя, что-то мне кажется, что все таки придется попробовать перелезть на БД, посмотреть, что получиться
Тем более все за это!!!

P/s для sharq - не принимай это близко, я и не думал как-то поддеть тебя

Цитата

Фима + реквизиты + шапка таблицы / Подзаголовок / Позиция прайса

Давай попробуем создать для этого дела 2 таблицы:
Первая будет хранить информацию о фирме, вторая о товаре. Примерно таким образом:

Код

# Таблица с данными о поставщике CREATE TABLE IF NOT EXISTS Firm (       Id            MEDIUMINT     UNSIGNED   NOT NULL   AUTO_INCREMENT,       Name          VARCHAR(100)             NOT NULL,       Address       VARCHAR(150)             NOT NULL,       City          VARCHAR(50)              NOT NULL,       Country       VARCHAR(50)              NOT NULL,       Phone         VARCHAR(20)              NOT NULL,       Fax           VARCHAR(20)              NOT NULL,       GSM           VARCHAR(20)              NOT NULL,       Email         VARCHAR(35)              NOT NULL,       Registration  TIMESTAMP                NOT NULL,       PRIMARY KEY( Id ) ); # Таблица с данными о товаре CREATE TABLE IF NOT EXISTS Product (       Id            BIGINT        UNSIGNED   NOT NULL   AUTO_INCREMENT,       Title         VARCHAR(50)              NOT NULL,       Quantity      SMALLINT      UNSIGNED   NOT NULL,       Price         SMALLINT      UNSIGNED   NOT NULL,       Picture       VARCHAR(200)             NOT NULL,       Description   VARCHAR(255)             NOT NULL,       Added         TIMESTAMP                NOT NULL,       AddedFrom     MEDIUMINT     UNSIGNED   NOT NULL,       PRIMARY KEY( Id ) );

Индексаций пока никаких нет, ну кроме PRIMARY KEY(). Следует теперь подумать, какие поля нужно добавить, а какие вообще не нужны. Так же стоит подумать о поле Description, в таблице Product, хватит ли нам 255 байт для описания товара? Какие поля будем индексировать?
Если не будет поиска по названию фирмы или по её адресу, то вообще таблицу Firm не нужно больше трогать, в ней нас интересует только Id, он уже установлен как PRIMARY KEY.

Что думаешь? Если есть идеи, выкладывай.

Это сообщение отредактировал(а) korob2001 - 24.8.2005, 21:48

Так вся проблема как раз в том, что, сильнее раздробить, чем выше предложил, не получится. Я писал, что прайсы в автоматическом режиме закачиваются на сервак, там же и конвертируются. Однако в связи со свободой оформления (кто как хочет так и делает) - разложить по полочкам каждый из них практически невозможно. Где 2 колонки в прайсе, а где и 14, где реквизиты фирмы указаны в одной строке, а где и замучаешься выделять из разных ячеек. Тем более, что некоторые фирмы периодически меняют структуру прайсов и заново все перебирать или отслеживать всевозможные изменений слишком геморрно. В текущем варианте, например, в первое поле таблицы (Фима + реквизиты + шапка таблицы) у меня попадает все от начала прайса до шапки включительно. Для пользователя такой вариан зачастую более чем достаточен.

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

Остается надеяться, что сама процедура поиска в БД работает гораздо быстрее, чем в Perle через m//.

Т.е. у тебя на текущий момент есть форма с одним или несколькими полями для выгрузки файлов и всё что ты имеешь, так это только прайс листы? И тебе нужно выдавать этот прайс не в виде HTML, а в виде отдельного файла?

Если да, то я бы сделал так:

1. Форма регистрации, с которой ты будешь получать информацию о фирме.

2. После регистрации фирма может добавлять свою продукцию, для этого создал бы вторую форму, которая доступна только зарегестрированным пользователям. Фирма вводит свой логин, пароль и получает доступ к этой форме. И пусть они добавляют информацию в эту форму, а не грузят твой сервак файлами.

3. Информация проверяется и сохраняется в БД.

4. Поиск делаешь по базе, что будет намного быстрее и не потому, что m// слишком медленный, а потому что там будет вся необходимая инфа проиндексирована и тебе будет достаточно сделать 1-2 запроса, что бы получить нужную информацию, а не открывать и закрывать тысячи файлов, а так же написать разумный запрос к базе куда легче, чем написать разумное регулярное выражение.

5. Юзеру выдаёшь прайс в HTML формате, вместе с сылокой "Конвертировать в PDF". Если юзер нажал на ссылку, то генерируешь PDF на лету, заполняешь его нужной информацией из базы и выдаёшь юзеру. Вот и будет ему счастье.
Для этого устанавливаешь соответствующий модуль, помоему вполне достаточно PDF::Create.

Экскурс по установке модулей можешь скачать отсюда:
http://forum.vingrad.ru/index.php?act=Atta...=post&id=494399
sharq - описал этот процесс во всех позах, за что ему и спасибо. Кстати в PDF формате.

По идее, это будет занимать гораздо меньше дискового пространства, поиск будет быстрее, вся инфа будет разложена по полочкам, юзер всегда может получить информацию ничего не скачивая, все сгенерированные прайс листы будут одного формата, что намного удобнее, меньше ресурсов будет расходоваться. В любой момент можешь спокойно сделать рассылку с какими либо новостями по всем или отобранным E-mail адресам из базы и т.д и т.п.

Вобщем сам смотри, я лишь сказал, как сделал бы я.

Я выше писал, что имею дело с готовыми прайсами. Просто на данный момент пытаюсь сворганить сайт с каталогом прайс-листов, но пока по-человечески не раскручусь, навязывать фирмам свою форму - это утопия. А подстраиваться под каждую - утопия вдвойне

Цитата

И тебе нужно выдавать этот прайс не в виде HTML, а в виде отдельного файла?

На данный момент выдаю в html-формате. Со временем возможно предложу и в PDF-формате. Как пойдет...

С остальными твоими аргументами полностью согласен, но как понимаешь, разложить прайсы по полочкам на текущий момент практически невозможно. Приходится иметь дело с тем, что есть. Часть прайсов я пока вообще не рассматриваю (*.doc и те *.хls, где, например, несколько таблиц с разной структурой на одном листе). Эту часть прайсов скорее всего придется выводить как, например, в Яндексе - просто ссылку - а там пусть закачивают его целиком, если нужно.

Если все пойдет хорошо, тогда и форму предложу

P/s За ссылку спасибо, правда модули я уже научился устанавливать. Но никогда не откажусь от разложенных по полочкам инструкций (букварей). Обычно ищешь в нете куски того, что нужно - часть работает, часть нет, а с букварями потом восполняешь пробелы.
А на счет того софта, который нужно установить, меня здесь в большей степени волнует сам mySQL и его настройка. Просто никогда с ним не работал и не знаю, что он захочет для нормальной работы. Хотя (как писал) это не самая большая проблем, надеюсь что все пройдет гладко…


Это сообщение отредактировал(а) Usya - 25.8.2005, 13:16

Usya то, что написал korob2001, действительно, разумный вариант! Ты себе придумал геморр с обработкой csv-файлов. Это было бы хорошо, если у тебя не было такого количества файлов.

Цитата(Usya @ 25.8.2005, 12:54)

А подстраиваться под каждую - утопия вдвойне

Это точно, подстраиваться под каждого это ужас, необходимо, чтобы был стандарт, формат (если угодно), под который все подтраиваются!

Цитата(Usya @ 25.8.2005, 12:54)

навязывать фирмам свою форму - это утопия.

нет, просто им надо сказать, мол для обновления своей информации используйте след. формы и Ваша информация будет отображаться на сайте и иначе никак.

Форма продукции должна позволять добавление, изменение и удаление информации.
Некоторый поля формы можно сделать в виде выпадающего списка, так будет удобнее для заполнителей и для анализа и внесения в БД информации.

Единственный минус такого варианта: каждый день (или период, за который меняется информация в фирме) необходимо добавлять (изменять) инфо о продукции, или добавлять по сотни товаров каждый день, со всеми их свойствами...

Кстати, ты можешь добавить возможность закачки прайсов фирм и все кто хотят смотрят или скачивают прайс.

Этот механизм можно автоматизировать только так: ввести для всех фирм стандарт, по которому они должны заполнять прайс, некоторый образец, который должен содержать то, то и то (это по структуре). И при закачки прайсов ты проверяешь, соблюдена ли структура закачиваемого документа (прайса фирмы). Если нет, пусть исправляют, если да, то парсишь этот прайс и заносишь всю необходимую информацию в таблицы БД. И работаешь опять только с БД.


Теперь ппо БД.

Цитата(Usya @ 25.8.2005, 12:54)

А на счет того софта, который нужно установить, меня здесь в большей степени волнует сам mySQL и его настройка. Просто никогда с ним не работал и не знаю, что он захочет для нормальной работы.

Тебе нужна БД MySQL, perl-модули DBI и DBD::mysql и все.

Цитата

Просто на данный момент пытаюсь сворганить сайт с каталогом прайс-листов, но пока по-человечески не раскручусь, навязывать фирмам свою форму - это утопия. А подстраиваться под каждую - утопия вдвойне.

Вот именно, под каждого не подстроишься.

Цитата

Часть прайсов я пока вообще не рассматриваю (*.doc и те *.хls, где, например, несколько таблиц с разной структурой на одном листе). Эту часть прайсов скорее всего придется выводить как, например, в Яндексе - просто ссылку - а там пусть закачивают его целиком, если нужно.

Большую часть вообще можно удалить, так как они устаревают очень быстро.

Ты просто должен понять, что чем быстрее, ты прийдёшь к нормальному стандарту, тем быстрее у тебя прекратятся головные боли.

Ну ладно, не буду навязывать тебе свои убеждения. Поступай так, как считаешь нужным.

sharq

Цитата

... необходимо, чтобы был стандарт, формат (если угодно), под который все подтраиваются!

korob2001

Цитата

... чем быстрее, ты прийдёшь к нормальному стандарту, тем быстрее у тебя прекратятся головные боли

Все зависит от того, как пойдет. Для крупных фирм, у которых регулярное обновление прайсов, я пока мелко плаваю, чтоб под меня подстраиваться и изменять наработанную годами структуру прайсов и соответствующее ПО для их формирования. У мелких - семь пятниц на неделе! Правда, насколько это возможно в автономном режиме, пытаюсь контролировать изменение в структуре прайсов.

Со временем при сопутствующей удаче, однозначно введу стандарт для фирм (если не для всех, то по крайней мере для большей части).

А на счет БД, как ни хотел я с ними связываться, УБЕДИЛИ!!!
По крайней мере попробую, а там посмотрим, насколько они будут прожорливыми в ресурсах...
Правда, скорее всего немного позже, ща со временем будет небольшая напряженка.

За советы и предложения СПАСИБО!!!
Надеюсь, не сильно ВАС замучил своими аргументами и вопросами

Это сообщение отредактировал(а) Usya - 26.8.2005, 09:45

Цитата

Все зависит от того, как пойдет. Для крупных фирм, у которых регулярное обновление прайсов, я пока мелко плаваю, чтоб под меня подстраиваться и изменять наработанную годами структуру прайсов и соответствующее ПО для их формирования. У мелких - семь пятниц на неделе! Правда, насколько это возможно в автономном режиме, пытаюсь контролировать изменение в структуре прайсов.

Ты попробуй, потому как нормальные фирмы тоже любят порядок и скорость. Для начала можно давать возможность заливать файлы, так как и заливают сейчас и создать для желающих форму и попутно разжевать им приимущества данного метода.

Цитата

По крайней мере попробую, а там посмотрим, насколько они будут прожорливыми в ресурсах...

Поверь, будет всё работать намного быстрее и ресурсов расходовать меньше.

Цитата

За советы и предложения СПАСИБО!!! Надеюсь, не сильно ВАС замучил своими аргументами и вопросами

Да незачто, пока толком ничего и не сделали, так поговорили.

Цитата

Для начала можно давать возможность заливать файлы, так как и заливают сейчас и создать для желающих форму и попутно разжевать им приимущества данного метода.

Не все пока знают, что их прайсы добавлены. Просто смысла не вижу об этом им сообщать, я ж их не ворую, они сами их выкладывают
А от некоторых фирм ответа не дождешься, приходиться пока работать с тем, что у них уже выложено на сайте.

Ладно, поживем, увидим...
Надо хоть более-менее по-человечески раскрутиться, тогда и фирмы будут заинтересованы. А то для них моя работа, как реклама на последнем столбу на окраине города Шучу конечно, кое-какой прогресс есть, кое-кто уже изменил прайсы в соответствии с определенными требованиями к структуре, да и посещаемость понемногу растет (это как бальзам на сердце)…

Могу предложить немного другое решение. Базы использовать полюбому, они для того и существуют. А вот этап нормализации можно продумать. Я не знаю как у тебя сейчас это работает, но я бы попробовал сделать так:
Для каждой фирмы у которой ты качаешь прайс пишется свой модуль, который парсит и нормализует данные. Идея понятна? Суть в том, что в случае изменения какой то фирмой формата прайса, ты правишь один маленький модуль. Для нормализации данных используется справочник подстановок. К примеру, в твоем мегапрайсе принтеры обозначаются как принтер, у одной эта же позиция пишется как prn, у другой принт., у третьей printer и т.п. У тебя есть таблица где пишется (prn, принт., printer) = принтер.
В итоге ты имеешь нормализованные данные, в едином формате не навязывая свой формат фирмам (тем более что это малореально, я с этим сталкивался уже). Когда раскрутишься просто попросишь при изменении формата извещать тебя об этом заранее, что бы ты мог пофиксить парсер для конкретного файла заранее.
Удачи!

Цитата(Kiber_rat @ 2.9.2005, 06:33)

Для каждой фирмы у которой ты качаешь прайс пишется свой модуль, который парсит и нормализует данные.

А если фирм 100??? Не оптимально.

Цитата(Kiber_rat @ 2.9.2005, 06:33)

К примеру, в твоем мегапрайсе принтеры обозначаются как принтер, у одной эта же позиция пишется как prn, у другой принт., у третьей printer и т.п. У тебя есть таблица где пишется (prn, принт., printer) = принтер.

Это идея.

Поэтому можно в одной программе делать такую проверку (как предлагал Kiber_rat с модулями), только у тебя будет словарь слов и сокращений (синонимов), с которым ты будешь работать.

В общем, продумать можно.

На счет

Цитата

Удачи!

спасибо!!! Она не помешает

А на счет остального - пробовал - вернее в начале все было так и задумано, но оказалось слишком геморрно. Взять, например, материнскую плату

Системная плата
MB
Мат. пл.
Плата MB
Плата системная
матер.плата
Материнская плата

плюс к тому же MB может быть набрано как русскими так и англ. буквами или и теми и др. вместе. Кроме того, насколько знаю, МВ - это компания по производству, продаже и обслуживанию копировальной и т.д. техники. Далее - в одних фирмах слово 'телефон' встречается у всех соответствующих товаров, в других введено деление на проводные, радиотелефоны и т.д. .. Вдобавок ко всему - одно дело, если товар как-то относится к компьютерам и т.п., в чем я разбираюсь, но разбираться во всех сокращениях и возможных названиях одних и тех же товаров - это...!!!

Хотя согласен, что доля разумного в этом есть. Возможно это и будет со временем как одна из услуг, но пока на данный момент я от этого отошел, но с сайта не убрал, думаю это полезно при раскрутке сайта и для повышения позиции в поисковиках.

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

http://price.ubd.ru

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

Это сообщение отредактировал(а) Usya - 2.9.2005, 20:53