nvarchar (max) против NText

Каковы преимущества и недостатки использования типов данных nvarchar(max)против и NTextв SQL Server? Мне не нужна обратная совместимость, поэтому хорошо, что nvarchar(max)она не поддерживается в старых версиях SQL Server.

Изменить: Очевидно, вопрос также относится к TEXTи IMAGEпротив varchar(max)и varbinary(max), для тех, кто ищет эти типы данных позже.

Преимущества , которые вы можете использовать такие функции , как LENи LEFTна , nvarchar(max)и вы не можете сделать это против ntextи text. С ним также легче работать, nvarchar(max)чем textтам, где вам приходилось использовать WRITETEXTи UPDATETEXT.

Кроме того , text, ntextи т.д., в настоящее время не рекомендуется ( http://msdn.microsoft.com/en-us/library/ms187993.aspx )

VARCHAR(MAX)достаточно большой, чтобы вместить TEXTполе. TEXT, NTEXTИ IMAGEтипы данных SQL Server 2000 будет устаревшим в версии будущего в SQL Server, SQL Server 2005 обеспечивает обратную совместимость с типами данных , но рекомендуется использовать новые типы данных , которые VARCHAR(MAX), NVARCHAR(MAX)и VARBINARY(MAX).

ntextвсегда будет хранить свои данные на отдельной странице базы данных, при этом nvarchar(max)будет пытаться сохранить данные в самой записи базы данных.

Так что nvarchar(max)это немного быстрее (если у вас есть текст, который меньше, чем 8 КБ). Я также заметил, что размер базы данных будет расти немного медленнее, это тоже хорошо.

Go nvarchar(max).

nvarchar(max)это то, что вы хотите использовать. Самое большое преимущество заключается в том, что вы можете использовать все строковые функции T-SQL для этого типа данных. Это невозможно с ntext. Я не знаю никаких реальных недостатков.

Вы, очевидно, должны использовать nvarchar(max):

MSDN

Самый большой недостаток Text(вместе с NTextи Image) заключается в том, что он будет удален в будущей версии SQL Server, как указано в документации . Это эффективно усложнит обновление вашей схемы после выпуска этой версии SQL Server.

Хотел добавить свой опыт с конвертированием. У меня было много textполей в древнем коде Linq2SQL. Это должно было позволить перестроитьtext столбцы в индексах ONLINE .

Сначала я знал о преимуществах в течение многих лет, но всегда предполагал, что преобразование будет означать несколько страшных длинных запросов, когда SQL Server придется перестраивать таблицу и копировать все, разрушая мои веб-сайты и повышая мою сердечность.

Я также был обеспокоен тем, что Linq2SQL может вызвать ошибки, если он выполняет какую-то проверку типа столбца.

Рад сообщить, что команды ALTER вернулись мгновенно - поэтому они определенно только меняют метаданные таблицы. Может случиться, что в автономном режиме будет выполнено возвращение данных <8000 символов в таблицу, но команда ALTER была мгновенной.

Я запустил следующее, чтобы найти все столбцы, нуждающиеся в преобразовании:

SELECT concat('ALTER TABLE dbo.[', table_name, '] ALTER COLUMN [', column_name, '] VARCHAR(MAX)'), table_name, column_name
FROM information_schema.columns where data_type = 'TEXT' order by table_name, column_name

SELECT concat('ALTER TABLE dbo.[', table_name, '] ALTER COLUMN [', column_name, '] NVARCHAR(MAX)'), table_name, column_name
FROM information_schema.columns where data_type = 'NTEXT' order by table_name, column_name

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

Linq2SQL довольно древний - он использует конструктор, на который вы перетаскиваете таблицы. Ситуация может быть более сложной для EF Code в первую очередь, но я еще не решил эту проблему.

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

Здесь вы можете найти полный пример использования .WRITEпредложения.