Стратегия для хранения строки неопределенной длины в Sql Server?

Question

Таким образом, столбец будет содержать некоторый текст, поэтому заранее я не буду знать, какой длины может быть длина этой строки. Реально в 95% случаев это, вероятно, будет между 100-500 символами, но может быть один случай, когда он будет иметь 10000 символов. У меня нет контроля над размером этой строки и никогда не делает пользователь. Кроме varchar (max), какие еще стратегии вы считаете полезными? И каковы некоторые недостатки varchar (max)?

Answer 1

Varchar (max) в sqlserver 2005 - это то, что я использую.

SqlServer странно обрабатывает большие строковые поля, в том случае, если вы указываете «текст» или большой varchar, но не max, он сохраняет часть битов в записи, а остальные - снаружи.

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

Answer 2

Один не элегантный, но эффективный подход состоял бы в том, чтобы в вашей таблице было два столбца: один достаточно большой, чтобы охватить большинство ваших дел, а другой - тип CLOB / TEXT для хранения странно больших столбцов. При вставке / обновлении вы можете получить размер вашей строки и сохранить ее в соответствующем столбце.

Как я уже сказал, не очень красиво, но это даст вам производительность varchar для большинства случаев, без поломок, когда у вас большие значения.

Answer 3

nvarchar (max) определенно является вашей лучшей ставкой - поскольку я уверен, что вы знаете, он выделит только пространство, необходимое для данных, которые вы фактически храните в каждой строке, а не фактический максимум типа данных в строке.

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

Answer 4

Рассматривали ли вы использование типа BLOB?

Кроме того, из любопытства, вы не контролируете размер строки, и пользователь не контролирует, кто это делает?