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