SQL Server 2005에서 nvarchar (255)와 같이 길이를 명시 적으로 지정하지 않고 모든 문자 필드를 nvarchar (MAX)로 만드는 데 단점이 있습니까? (데이터베이스 수준에서 필드 길이를 제한 할 수 없다는 것은 분명합니다)
답변
MSDN 포럼에서도 동일한 질문이 제기되었습니다.
원래 게시물에서 (더 많은 정보가 있습니다) :
VARCHAR (N) 열에 데이터를 저장할 때 값은 실제로 동일한 방식으로 저장됩니다. 그러나 VARCHAR (MAX) 열에 저장하면 화면 뒤에서 데이터가 TEXT 값으로 처리됩니다. 따라서 VARCHAR (MAX) 값을 처리 할 때 몇 가지 추가 처리가 필요합니다. (크기가 8000을 초과하는 경우에만)
VARCHAR (MAX) 또는 NVARCHAR (MAX)는 ‘큰 값 유형’으로 간주됩니다. 큰 값 유형은 일반적으로 ‘out of row’로 저장됩니다. 데이터 행에 ‘큰 값’이 저장된 다른 위치에 대한 포인터가 있음을 의미합니다 …
답변
그것은 공정한 질문이며 명백한 것과는 별개로 진술했습니다…
단점은 다음과 같습니다.
성능 영향 쿼리 최적화 프로그램은 필드 크기를 사용하여 가장 효율적인 실행 계획을 결정합니다.
“1. 데이터베이스의 확장 영역과 페이지의 공간 할당이 유연합니다. 따라서 업데이트를 사용하여 필드에 정보를 추가 할 때 새 데이터가 이전에 삽입 된 것보다 길면 데이터베이스가 포인터를 작성해야합니다.이 데이터베이스 파일은 인덱스에서 삭제, 업데이트 및 삽입에 이르기까지 거의 모든 부분에서 성능이 저하됨 = ”
http://sqlblogcasts.com/blogs/simons/archive/2006/02/28/Why-use-anything-but-varchar_2800_max_2900_.aspx
통합 시사점-다른 시스템이 데이터베이스와 통합하는 방법을 알기 어렵다 예상치 못한 데이터 증가 가능한 보안 문제 (예 : 모든 디스크 공간을 차지하여 시스템 충돌)
여기에 좋은 기사가 있습니다 :
http://searchsqlserver.techtarget.com/tip/1,289483,sid87_gci1098157,00.html
답변
허용 된 답변에 제공된 링크를 기반으로 다음과 같이 나타납니다.
-
nvarchar(MAX)
필드에 저장된 100 문자는 필드에 100 문자와 다르지 않게 저장됩니다nvarchar(100)
. 데이터는 인라인으로 저장되며 데이터를 ‘out of row’로 읽고 쓰는 오버 헤드가 없습니다. 그래서 걱정할 필요가 없습니다. -
크기가 4000보다 크면 데이터가 자동으로 ‘out of row’로 저장됩니다. 그래서 걱정도 없습니다.
하나…
- 에 색인을 만들 수 없습니다
nvarchar(MAX)
열에 . 전체 텍스트 인덱싱을 사용할 수 있지만 쿼리 성능을 향상시키기 위해 열에 인덱스를 만들 수는 없습니다. 나에게 이것은 거래를 봉쇄합니다 … 항상 nvarchar (MAX)를 사용하는 것이 확실한 단점입니다.
결론:
인덱싱 할 수 있고 공간과 액세스 시간을 낭비하지 않는 전체 데이터베이스에서 일종의 “유니버설 문자열 길이”를 원한다면을 사용할 수 있습니다 nvarchar(4000)
.
답변
때로는 데이터 유형이 데이터에 의미를 부여하기를 원할 때가 있습니다.
예를 들어 실제로 20 자보다 길면 안되는 열이 있다고 가정하십시오. 해당 열을 VARCHAR (MAX)로 정의하면 일부 불량 응용 프로그램에서 긴 문자열을 삽입 할 수 있으며 알 수 없거나 방지 할 방법이 없습니다.
다음에 응용 프로그램에서 해당 문자열을 사용할 때 문자열의 길이가 적당하고 문자열이 대표하는 도메인이라는 가정하에 예측할 수없고 혼란스러운 결과가 발생합니다.
답변
내가 어떤 기사를 확인하고이에서 유용한 테스트 스크립트를 찾을 수 : http://www.sqlservercentral.com/Forums/Topic1480639-1292-1.aspx은
다음 NVARCHAR 대 NVARCHAR (4000) 대 NVARCHAR (10) (MAX 사이의 비교를 변경 )와 지정된 숫자를 사용할 때 속도 차이를 찾지 못하지만 MAX를 사용할 때. 혼자서 테스트 할 수 있습니다. 희망이 도움이됩니다.
SET NOCOUNT ON;
--===== Test Variable Assignment 1,000,000 times using NVARCHAR(10)
DECLARE @SomeString NVARCHAR(10),
@StartTime DATETIME;
--=====
SELECT @startTime = GETDATE();
SELECT TOP 1000000
@SomeString = 'ABC'
FROM master.sys.all_columns ac1,
master.sys.all_columns ac2;
SELECT testTime='10', Duration = DATEDIFF(ms,@StartTime,GETDATE());
GO
--===== Test Variable Assignment 1,000,000 times using NVARCHAR(4000)
DECLARE @SomeString NVARCHAR(4000),
@StartTime DATETIME;
SELECT @startTime = GETDATE();
SELECT TOP 1000000
@SomeString = 'ABC'
FROM master.sys.all_columns ac1,
master.sys.all_columns ac2;
SELECT testTime='4000', Duration = DATEDIFF(ms,@StartTime,GETDATE());
GO
--===== Test Variable Assignment 1,000,000 times using NVARCHAR(MAX)
DECLARE @SomeString NVARCHAR(MAX),
@StartTime DATETIME;
SELECT @startTime = GETDATE();
SELECT TOP 1000000
@SomeString = 'ABC'
FROM master.sys.all_columns ac1,
master.sys.all_columns ac2;
SELECT testTime='MAX', Duration = DATEDIFF(ms,@StartTime,GETDATE());
GO
답변
다른 안전 수준으로 생각하십시오. 외래 키 관계없이 완벽하게 유효한 테이블을 설계하고 비즈니스 계층에 관련 엔터티가 존재하는지 확인할 수 있습니다. 그러나 외래 키는 비즈니스 계층에서 문제가 발생하는 경우 다른 제약 수준을 추가하기 때문에 좋은 설계 방식으로 간주됩니다. varchar MAX를 사용하지 않고 필드 크기 제한도 마찬가지입니다.
답변
max 또는 text 필드를 사용하지 않는 이유는 SQL Server Enterprise Edition에서도 온라인 인덱스 재 구축을 수행 할 수 없기 때문입니다. 즉 REBUILD WITH ONLINE = ON입니다.