MySQL, разнородные данные, индексация
 

Необходимо разработать БД на основе MySQL, в которой будет храниться разнородная информация: .txt, .doc, .xls, etc... Необходимо реализовать полнотекстовый поиск по базе.
Вопрос: как это сделать? Бинарники хранить в blob-ах? Или в базе хранить толко ссылки на файлы и индексы? А как вообще быть с DOC-ами? Есть в MySQL (или в PHP) средства импорта/экспорта в DOC/XLS ?

Уважаемые программеры, посоветуйте чего дельного, пожалуйста...

невыполнимо.
как ты планируешь на лету sql-запросом просканировать *.xls файл?

измени исходные условия, например, введи ключевые слова.

Однозначно выполнимо. Только вот как...
Нет. Я не планирую сканировать "на лету". При загрузке документа в базу будет проводиться его индексация и в базу ляжет индекс данного документа, по которому в последствии и будет вестись поиск. Вот как эту индексацию делать. Есть способы кроме OLE, например? Может быть есть какие-то сторонние библиотеки/модули под мускл/пхп ?

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

не вполне представляю, как можно "проиндексировать" рабочую книгу экселя?
или как по ней затем выполнить полнотекстовый поиск?
сканирование таблицы "на лету", пожалуй, единственный приемлемый способ по скорости выполнения. если же ты хочешь дополнительными средствами разбирать блоб вне mysql - ну ты и получишь в час по чайной ложке. что касается расширений языка sql-92 - ну да, есть pl-sql. но даже и в нём я не припомню подобной функциональности, хотя это совершенно иной уровень.

Если *.doc новый, 2003 - то пробем не будет, ибо это xml. Если старый - то да. Слыхал, что есть класс для работы с *.doc, но на perl. Если дело планируеться на винде (что мало вероятно для php), то есть скоростная утилитка zd2t.exe. Она у меня к фару прилеплена как просмоторшик. Для люни? Да должно быть чего, в крайнем случае (но до этого дело вряд ли дойдет) выдерни исходники и abiword к примеру. Но это вряд ли, экспортер должен быть.
*.xls - вроде есть бибка какая то. Непомню.
Индексировать бинарные файлы этих докуменов я смысла не вижу.

Где хранить - в бд или в катологах решать вам. Но как юзер скажу - в катологах в разы лучше. Нет лишней нагрузки на бд. Но зато нет зашиты от левых скачиваний.

Кароче, чё здесь тему разводить? Поисковики заплесневеют...

Про полнотекстовый поиск можешь начинать читать отсюда http://linguist.nm.ru/ В MS SQL он уже встроен - если тебе не критичен движок БД, то можешь посмортеть в его сторону. Если использовать Interbase на Windows, то можно воспользоваться библиотекой полнотекстового поиска отсюда http://www.textolution.com/ftsib.asp

Экспорт/Импорт в офисные документы можно делать либо руками где угодно (форматы файлов можешь найти здесь http://www.wotsit.org/) либо под Windows: за деньги - http://wordcnv.com/dev.html, бесплатно - использовать конвертеры от MS, которые идут вместе с офисом или бесплатными смотрелками документов.

Как хранить? К тому моменту как ты разберешся с индексацией и полнотекстовым поиском обычного текста вопрос хранения документов у тебя решится сам собой :)

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

задам ещё раз вопрос - поясни пожалуйста, что ты подразумеваешь под "индексацией" документа? то есть, поясни в деталях. "ту же" - я честно говоря, не вполне представляю.

и ещё один вопрос, повторно -
не вполне представляю, как можно "проиндексировать" рабочую книгу экселя, да ещё и средствами сервера БД. как это можно проделать?

угу, конечно. ну имеешь ты в блобе 5мег xml-а, и твои действия? средствами сервера ты всё равно в нём искать не сможешь, будет необходим дополнительный слой, значит скорость уменьшится ГОРАЗДО.

Некоторые уточнения.

Платформа: Win.
Инструментарий: PHP+MySQL.
Входные данные: TXT, DOC, XLS, PDF (etc, may be...)
Требуется реализовать полнотекстовый поиск.

Соображения на данный момент такие. В БД грузится документ-исходник и его т.н. унифицированное(внутреннее) представление - простая текстовая форма. В принципе кое-какие консольные конвертеры я уже откопал. Далее вопрос уже такой: как реализовать поиск? Просто искать средствами MySQL по текстовым формам? Или попытаться соорудить собственный индекс, хранить его в базе и искать уже по нему?

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

Следующий этап: для оптимизации таблиц вводится термин "стоп слово". Это слова не несущие содержательного смысла: предлоги, союзы, частицы и разные часто употребимые слова. Такие слова не заносятся.

Следующий этап: для поиска фраз и нечеткого поиска вводится понятие расстояния между словами.

Следующий этап: для поиска по всем словоформам в словарь слов добавляется инвариант слова. Т.е. слово без приставок, суффиксов и окончаний. Этим занимается морфологический анализатор или стеммер.

Следующий этап: вводится понятие ранга или веса документа, т.е. насколько этот документ полезен для пользователя. Ранг расчитывается по хитрой формуле, учитывающий "заточенность" документа под какую-то тему и "индекс цитируемости". Но этим как правило заморчиваюся поисковики масштаба предприятия как минимум (напр Google-Mini).
См. выше. Более того в MS SQL уже встроен механизм полнотекстового поиска. Ссылку на движок для Interbase я уже приводил.
С чего ты это взял? А как по твоему работают индексы в БД? Это именно дополнительные слои, которые представляют собой B-деревья (каждый узел дерева - это отсортированный список из N элементов) Дерево пересобирается каждый раз когда когда ты меняешь что-то в базе. Причем сколько индексов в базе - столько и этих дополнительных структур. И никто не жалуется :)
Замени MySQL на MS SQL или Interbase (или Firebird - он бесплатный) + FastTextSearch и твоя задача сводится к написанию/поиску конвертеров и оболочки.

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