SqlServer и nvarchar (макс.) - PullRequest
Новая
       7

SqlServer и nvarchar (макс.)

5 голосов
/ 02 февраля 2011

В настоящее время мы стремимся установить для наших строковых столбцов значение nvarchar(max), а не указывать конкретную длину во избежание проблем, когда в базе данных может не хватить места для хранения строки.Мне просто интересно, если это хорошо или это может вызвать какие-либо проблемы, так как это было нормально, тогда зачем указывать длину, например nvarchar(10), а не nvarchar(max).Мы также часто используем varbinary(max), так как мы не знаем, сколько двоичных данных нам понадобится, поэтому я не уверен, насколько это эффект, либо потому, что наши вставки работают не так быстро, как мне кажется.Вот пример таблицы: 

CREATE TABLE [dbo].[SAMPLETABLE] (  
[ID] [uniqueidentifier] NOT NULL,  
[FIELD1] [int] NOT NULL,  
[FIELD2] [nvarchar] (2000) NULL,  
[FIELD3] [nvarchar] (max) NULL,  
[FIELD4] [uniqueidentifier] NULL,  
[FIELD5] [int] NULL,  
[FIELD6] [nvarchar] (2000) NULL,  
[FIELD7] [varbinary] (max) NULL,  
[FIELD8] [varbinary] (max) NULL,  
[FIELD9] [varbinary] (max) NULL,  
[FIELD10] [uniqueidentifier] NULL,  
[FIELD11] [nvarchar] (2000) NULL,  
[FIELD12] [varbinary] (max) NULL,  
[FIELD13] [varbinary] (max) NULL,  
[FIELD14] [bit] NULL,  
[FIELD15] [uniqueidentifier] NULL,  
[FIELD16] [varbinary] (max) NULL,  
[FIELD17] [bit] NULL,  
[FIELD18] [tinyint] NULL,  
[FIELD19] [datetime] NULL,  
[FIELD20] [nvarchar] (2000) NULL,  
PRIMARY KEY CLUSTERED   
(  
    [ID] ASC  
)
) ON [PRIMARY]  

GO

При таком дизайне таблицы и изменении nvarchar(2000) на nvarchar(max) это ухудшит (или улучшит) ситуацию?Sqlserver не одобряет подобные проекты?

Ответы [ 6 ]

11 голосов
/ 02 февраля 2011

Если вы счастливы, что J. Random Developer, 6 месяцев спустя, вставит произведение Шекспира в каждый столбец, тогда хорошо.

Для меня большая часть моделирования данных - это серьезно.думать о том, какие данные я хочу разрешить в каждом столбце, и какие данные я хочу запретить.Затем я применяю соответствующие ограничения CHECK для достижения этих ограничений (насколько позволяет SQL Server).Наличие разумной проверки длины, доступной «бесплатно», всегда казалось бонусом.

Вы также не проводите много «проверок на будущее» - изменив длину столбца (n) varchar наЯ полагаю, что большее значение на более позднем этапе является чисто метаданными.Поэтому я бы сказал, что размер столбцов должен соответствовать данным, с которыми вы собираетесь работать сегодня (и хорошо, на следующий год или около того).Если вам потребуется расширить их позже, это займет несколько секунд.

5 голосов
/ 02 февраля 2011

Будем надеяться, что вы не используете столбец для поиска или у вас есть уникальные значения ...

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

  • очень плохая производительность поиска
  • нет уникальных ограничений

Его можно обойти с вычисляемым столбцом, но почему бы не сохранить то, что вам нужно ?

4 голосов
/ 02 февраля 2011

Переключение со строчных типов на BLOB-типы всегда является важным решением. Вы должны усвоить, что типы BLOB (VARCHAR(MAX), NVARCHAR(MAX) и VARBINARY(MAX)) полностью отличаются от внутренних типов:

Таким образом, переключение всех столбцов на типы BLOB может привести к множеству побочных эффектов, которые вы не рассматривали: невозможность индексировать столбцы BLOB, отсутствие оперативных операций, общее снижение производительности из-за медленного кода, присущего BLOB, и т. Д. И т. Д., Наиболее серьезные Препятствием может быть тот факт, что вы не сможете индексировать столбцы после создания их BLOB-объектов. Если это не ограничитель показа, вам придется протестировать и измерить влияние на производительность.

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

3 голосов
/ 02 февраля 2011

Ответ совпадает с ответом на вопрос «Почему мне нужно указывать int, когда я могу хранить все числа в виде строк?»- потому что это помогает:

  • эффективность скорости.
  • эффективность хранения.
  • намерение автора / архитектора.
  • сокращает данныеошибка, так как подойдет только определенный тип данных.

Но это не вызовет никаких явных "проблем" сразу, потому что nvarchar (10) является подмножеством nvarchar (max).

0 голосов
/ 07 июня 2016

По моему опыту, не все поля длиной 2000 символов индексируются.Я думаю, что гораздо лучше использовать nvarchar (max), чем некоторую произвольную длину, для которой вам может потребоваться усечь данные, если они недостаточно длинные.

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

0 голосов
/ 15 августа 2014

Вот тот же ответ, который я дал другому парню, который хотел бесконечные столы:

Альтернатива базы данных MySQL для миллионов таблиц

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

Возможно, решение без sql подойдет лучше, так что вы можете иметь динамические данные и не беспокоиться о пределах столбцов.

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

Думайте о парне, который идет за вами, как сказал КМ выше

...