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

Question

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

<TextView
    android:id="@+id/textView3"
    android:layout_width="match_parent"
    android:layout_height="2dp"
    android:background="#72cdf4"
    android:text=" aa" />

Просто добавьте этот TextView под текстом, в который вы хотите добавить рамку

43

xml database

задан Etzeitet 5 July 2009 в 17:47

4 ответа

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

4

ответ дан 26 November 2019 в 23:09

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

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

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

9

ответ дан 26 November 2019 в 23:09

Взгляните на родные базы данных xml. Их несколько, и некоторые из них бесплатны.

Поиск в eXist, Document xDB, Oracle Berkeley.

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

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

2

ответ дан 26 November 2019 в 23:09

Другие вопросы по тегам:

xml database

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

score 21 · Accepted Answer

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

Редактировать

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

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

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

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

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

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

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

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

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

Удачи!