Вопрос по database, xml – Как хранить статьи или другие большие тексты в базе данных

34

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

Хотя я считаю, что дизайн моей базы данных пока неплох, я все еще не совсем уверен в том, как лучше хранить статьи или другие большие тексты. Я знаю, что большинство СУБД имеют тип данных TEXT или эквивалентный и могут содержать огромное количество текста. Однако хранение полной статьи в виде одной длинной строки приводит к несчастному чтению, поэтому форматирование будет необходимо.

Сохраняю ли я текст статьи вместе со всеми тегами HTML или BBcode - или лучше просто создать страницу в документе HTML или XML и сохранить путь к этому файлу в БД?

Мне очень нравится идея хранить статьи в виде XML-документа, поскольку я могу легко разметить статью с помощью пользовательских тегов и использовать PHP-функции XML и XSLT для преобразования XML в HTML [или даже в любой другой формат]. Это также позволяет автору определять, когда создавать разрывы строк / страниц. Этот подход, конечно, потребует дополнительного кодирования [которого я не боюсь], но он создает проблему с поиском статей.

Я знаю, что MySQL, например, имеет синтаксис SQL для поиска определенных терминов / фраз внутри строк, содержащихся в текстовом поле. Если бы я мог хранить текст в отдельных файлах, как бы я мог сделать эти статьи доступными для поиска?

Здесь достаточно много написано по такому простому вопросу, поэтому я разобью его:

1: есть ли "лучший" способ хранения большого количества форматированного текста непосредственно в базе данных или
2: лучше ли хранить пути к этому тексту в виде HTML / XML / любых документов.

Если 2, есть ли элегантный способ сделать этот текст доступным для поиска?

Спасибо за ваше время :)

Ваш Ответ

4   ответа
20

как предложила Алекс. Для поиска, не забивайте свою базу данных, используйтеLucene, или жеhtdig создать индекс вашего вывода. Этот способ поиска очень быстрый. Побочным эффектом является то, что вы делаете свои поиски немного более дружественными для поисковых систем; Вы берете поле ключевых слов (как предложено с обратной косой чертой) и вставляете их в атрибут мета-ключевых слов.

Edit

Если вы не ищете только ключевые слова, поиск в db будет ужасно медленным (когда-либо искали на форуме, и это НАВСЕГДА?). База данных не может проиндексировать

  select.. where FULLTEXTFIELD like '%cookies%'.  

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

Еще одно преимущество - нечеткое соответствие. Если вы ищете «активировать» htdigg будет соответствовать страницам, которые имеют активную, активацию, активность и т. д. (настраивается). Или, если пользователь введет слово с ошибкой, оно все равно будет найдено. Вы хотите, чтобы ваши пользователи имели опыт, подобный Google, а не раздражающий. :)

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

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

Что касается поля ключевых слов, выshould иметь отдельную таблицу под названием ключевые слова с идентификатором статьи и полем ключевых слов (1 ключевое слово в строке). Но для простоты наличие единственного поля в db не является ужасной идеей, поэтому довольно просто обновить ключевые слова, если поместить их в форму.

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

Удачи!

Error: User Rate Limit Exceeded Etzeitet
3

как вы все организовали и установили, может быть сложно получить доступ к внешним файлам от удаленных клиентов, которые могут обращаться к БД просто отлично - так почему бы вместо этого не сохранить все XML в одном поле TEXT? Вы можете выполнить рефакторинг, чтобы оптимизировать его позже, если механизм БД не может справиться с такой нагрузкой, но это самый простой способ начать работу.

9

BIGTEXT, LONGTEXT и других были созданы для хранения большого объема текста (от 64 КБ до 4 ГБ в зависимости от РСУБД). Они просто создают двоичный указатель, чтобы найти текст в базе данных, и он не сохраняется непосредственно в таблице. Это почти та же процедура, если вы сохраняете путь в поле varchar для поиска документа, но наличие его в базе данных облегчает его обслуживание, поскольку при удалении строки документ исчезает вместе с ней без необходимости удалять его в другой процедуре. (как будто вы сохранены в виде файла). По логике это делает вашу базу данных больше, а иногда ее не так просто выполнять резервное копирование и перенос, но переносить документы по одному будет утомительно и медленно.

Как видите, это зависит от количества документов и строк в базе данных.

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

2

и некоторые очень хорошие бесплатны.

Поиск eXist, Документ xDB, Oracle Беркли.

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

Перед тем, как приступить к разработке, прочитайте немного о XPath и XQuery. Вот хорошее место для начала:https://community.emc.com/community/edn/xmltech

Похожие вопросы