Каков канонический способ хранения произвольного (возможно размеченного) текста в SQL?

Question

Что делают вики / stackoverflow / и т.д. делать, когда дело доходит до хранения текста? Текст разбит на новые строки? Это разбито на куски фиксированной длины? Как лучше всего хранить произвольно длинные куски текста?

Answer 1

nvarchar (max) ftw. потому что усложнять простые вещи - это плохо, ммк?

Answer 2

Полагаю, если вам нужно предложить возможность хранить большие куски текста, и вы не возражаете, если не будете слишком часто просматривать их содержимое при запросах, вы можете использовать CLobs.

Answer 3

Относительно PostgreSQL - используйте тип TEXT или BYTEA . Если вам нужно прочитать случайные куски, вы можете рассмотреть большие объекты .

Answer 4

Все это зависит от используемой СУБД, а также от типов текста, который вы собираетесь хранить. Если текст отформатирован в значительных порциях данных, которые сами по себе что-то значат, например, скажем, заголовок / тело, то вы можете разбить данные на столбцы этих типов. Для использования этого метода может потребоваться несколько таблиц в зависимости от содержимого, с которым вы имеете дело.

Я не знаю, как другие СУБД справляются с этим, но я знаю, что не стоит иметь более одного открытого столбца в каждой таблице (text или varchar (max)). Поэтому вам нужно убедиться, что только в одном столбце есть неограниченное количество символов.

Answer 5

Для SQL Server:

Используйте вархар (макс) для хранения. Я думаю, что верхний предел составляет 2 ГБ.

Не пытайтесь убежать от текста самостоятельно. Передайте текст через параметризованную структуру, которая сделает переходы правильно для вас. В .Net вы добавляете параметр в SqlCommand или просто используете LinqToSQL (который затем управляет SqlCommand для вас).

Answer 6

Я думаю, это зависит от того, где вы хотите хранить текст, если вам нужны такие вещи, как транзакции и т. Д.

Базы данных, такие как SQL Server, имеют тип, который может хранить длинные текстовые поля. В SQL Server 2005 это в первую очередь будет nvarchar (max) для длинных текстовых строк Unicode. Используя базу данных, вы можете извлечь выгоду из транзакций и простого резервного копирования / восстановления, если вы используете базу данных для других целей, таких как StackOverflow.com.

Альтернатива - хранить текст в файлах на диске. Это может быть довольно просто реализовать и может работать в средах, где база данных недоступна или излишняя.

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

Следует помнить, что вы, вероятно, хотите использовать Unicode или UTF-8 от создания до хранения и наоборот. Это позволит вам поддерживать дополнительные языки. Любая проблема с этим механизмом кодирования повредит ваш текст. Исторически люди могли использовать ASCII по умолчанию, исходя из предположения, что они экономили дисковое пространство и т. Д.

Answer 7

Я подозреваю, что StackOverflow хранит текст в формате уценки в столбце «текст» произвольного размера. Может быть, как UTF8 (но это может быть UTF16 или что-то в этом роде. Я предполагаю, что это SQL Server, о котором я мало что знаю).

Как правило, вы хотите хранить вещи в своей базе данных в «самой необработанной» форме. То есть делайте все свое декодирование и, возможно, очистку, но ничего с этим не делайте (например, если это Markdown, не кодируйте его в HTML, оставьте его в исходном «сыром» формате)

Answer 8

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

В большинстве языков сценариев есть встроенные инструменты для этого.