Каков наилучший способ хранения большого объема текста в таблице сервера SQL?

Question

Каков наилучший способ хранения большого количества текста в таблице на сервере SQL?

Надежен ли varchar (max)?

Answer 1

В SQL 2005 и выше VARCHAR (MAX) действительно является предпочтительным методом. Тип TEXT по-прежнему доступен, но в основном для обратной совместимости с SQL 2000 и ниже.

Answer 2

Мне нравится использовать VARCHAR (MAX) (или фактически NVARCHAR), потому что он работает как стандартное поле VARCHAR. Поскольку это введение, я использую его, а не поля TEXT, когда это возможно.

Answer 3

Разделите текст на куски, которые ваша база данных может обработать. И поместите разделенный текст в другую таблицу. Используйте id из таблицы text_chunk как text_chunk_id в исходной таблице. Возможно, вы захотите, чтобы другой столбец в вашей таблице содержал текст, который соответствует вашему наибольшему типу текстовых данных.

CREATE TABLE text_chunk (
     id NUMBER,
     chunk_sequence NUMBER,
     text BIGTEXT)

Answer 4

Varchar (max) доступен только в SQL 2005 или более поздней версии. Это будет хранить до 2 ГБ и может рассматриваться как обычный varchar. До SQL 2005 используйте тип text.

Answer 5

Согласно найденному тексту здесь , varbinary (max) - это путь. Вы сможете хранить приблизительно 2 ГБ данных.

Answer 6

В BLOB

BLOB - это очень большие переменные двоичные или символьные данные, обычно документы (.txt, .doc) и изображения (.jpeg, .gif, .bmp), которые могут храниться в базе данных. В SQL Server BLOB могут быть текстовыми, текстовыми или графическими типами данных, вы можете использовать текстовый тип

текст

Данные не-Unicode переменной длины, хранящиеся на кодовой странице сервера, с максимальной длиной 231 - 1 (2 147 483 647) символов.

Answer 7

Используйте nvarchar(max), чтобы сохранить всю цепочку чата в одной записи. Каждое отдельное текстовое сообщение (или блок) идентифицируется в тексте содержимого путем вставки маркеров.

Пример:

{{UserId: Date and time}}<Chat Text>. 

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