Как хранить статьи или другие большие тексты в базе данных

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

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

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

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

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

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

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

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

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

Ответ 1

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

Изменить

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

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

Неудобно искать статью, и поиск не возвращает результаты, которые вы ищете, потому что они не были в поле ключевых слов! Htdig позволяет вам эффективно искать полный текст статьи. Ваши поисковые запросы будут возвращены мгновенно, и КАЖДЫЙ термин в статье будет полностью доступен для поиска. Помещение ключевых слов в метатеги сделает запросы на этих условиях выше на странице результатов.

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

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

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

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

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

Удачи!

Ответ 2

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

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

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

Ответ 3

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

Ответ 4

Взгляните на собственные XML файлы. Их несколько, а некоторые очень хорошие.

Поиск eXist, документ xDB, Oracle Berkeley.

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

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