nvarchar (макс.) проти 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 кБ). Я також помітив, що розмір бази даних буде рости трохи повільніше, це теж добре.

Іди 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, але я цього ще не вирішував.

Хочу додати, що ви можете використовувати пункт .WRITE для часткових або повних оновлень та додавання високої продуктивності до varchar(max)/nvarchar(max)типів даних.

Тут ви можете знайти повний приклад використання .WRITEпункту.