хранение длинного текста

Question

Как лучше хранить длинные тексты (статьи) в базе данных? он не должен быть доступен для поиска.

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

РЕДАКТИРОВАТЬ: доступ к базе данных

Answer 1

Если это sql server 2005, ИСПОЛЬЗОВАТЬ VARCHAR (MAX)

EDIT

Кажется, он говорит:

так что я бы пошел с памяткой

До 63 999 символов. (Если памятка поле манипулируется через DAO и только текст и цифры [не двоичные данные] будет храниться в нем, затем размер поля Memo ограничен размер базы данных.)

или объект OLE (если можете)

Объект (например, Microsoft Excel электронная таблица, Microsoft Word документ, графика, звуки или другое двоичные данные) связаны (ссылка OLE / DDE: A связь между объектом OLE и его OLE-сервер, или между динамическим Исходный документ обмена данными (DDE) и документ назначения.) или встроенный (вставлять: вставить копию объект OLE от другого приложение. Источник объекта, называется OLE сервером, может быть любым приложение, которое поддерживает объект связывание и встраивание. Изменения в встроенный объект не отражается в оригинальный объект.) в Microsoft Таблица доступа.

до 1 гигабайта (ограничено доступным дисковое пространство)

Answer 2

Я не буду хранить какие-либо документы в базе данных, но буду хранить данные в файлах в файловой системе, и единственное, что находится в базе данных, это указатель на файлы данных.

Вы не предоставили в своем вопросе никаких подробностей, которые указывали бы на необходимость хранить документы в самой базе данных.

И очень мало обстоятельств, когда это выгодно.

Answer 3

Основное различие между длинным текстом (CLOB / TEXT / VARCHAR(MAX)) и длинными данными (BLOB / IMAGE / VARBINARY(MAX)) заключается в том, что первый подлежит преобразованию набора символов, а первый - нет.

Если вам нужно выполнить преобразование набора символов на стороне базы данных, используйте CLOB и аналогичные.

Если вы всегда хотите получать данные в том виде, в каком они были у вас, побайтно (в отличие от символьно-символьного), используйте BLOB и т.

Answer 4

у вас есть несколько вариантов:

• сохраните его как одну длинную строку без форматирования, которая будет выглядеть мягко на экране.

• храните его как длинную строку со встроенными html и css, что будет плохим выбором, если вы когда-нибудь захотите, чтобы ваш сайт выглядел по-другому.

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

Answer 5

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

Поля могут быть nvarchar (MAX), если вы используете MS SQL Server 2008 или любой другой эквивалентный тип данных в других базах данных.

EDIT: Кажется, вы используете Access, так что переходите на тип данных Memo! Если вы решили хранить HTML, рассмотрите возможность хранения только общей разметки (div, p) для разделения текста, а затем примените форматирование CSS, оборачивая сохраненный текст в другой div, определяющий классы форматирования для дочерних элементов.

Answer 6

Следующее относится только к Jet 4.0, являющемуся версией ядра СУБД Access в эпоху от Access2000 до Access2003 включительно:

Я не буду хранить какие-либо документы в базе данных, но буду хранить данные в файлах в файловой системе, и единственное, что находится в базе данных, это указатель на файлы данных.

Вы не предоставили в своем вопросе никаких подробностей, которые указывали бы на необходимость хранить документы в самой базе данных.

И очень мало обстоятельств, когда это выгодно.

Если вы используете ACE, являющуюся версией ядра СУБД Access в эпоху Access2007, тип данных Attachment был бы вариантом, однако я не знаю, как он работает, я никогда не использовал его, не могу рекомендовать это или сказать, лучше это или хуже для этой цели. Я также опасаюсь новых типов данных в первом выпуске основной версии Access Database Engine. Я просто помню все проблемы с байтовыми и десятичными полями при представлении Jet 4 и не хочу фиксировать что-то, что может никогда не работать должным образом. Тип Attachment в формате ACCDB был введен для совместимости с Sharepoint, и эта внешняя зависимость - это то, что заставляет меня задуматься. Изменится ли тип данных ACCEDB когда-нибудь, если Sharepoint изменит способ, которым он работает? Я не уверен, что хотел бы пойти на такой риск.

Answer 7

Я бы предложил сохранить первую главу в формате PDF.Это безопасно и позволяет хорошее форматирование.Затем используйте blob, clob, varchar или текстовое поле в зависимости от вашего продукта (см. Другие ответы).

Или вы можете использовать изображения и посмотреть что-то вроде «взгляда изнутри» amazone.Он будет работать с теми же приемами БД.

В качестве альтернативы вы можете использовать что-то вроде разметки.

Лично я не люблю помещать html в свою базу данных.Даже если это только для вывода.Слишком легко вставить какой-нибудь javascript.Но, может быть, я просто слишком осторожен.

Answer 8

для SQL Server

TEXT / NTEXT для SQL Server 2000

VARCHAR(MAX) / NVARCHAR(MAX) для SQL Server 2005 и далее

Answer 9

Поместите его в поле TEXT и укажите его <p>, чтобы вы могли оформлять абзацы.

Поскольку его не нужно искать, это не повлияет на производительность SQL.

Answer 10

Используйте CLOB .