항상 NVARCHAR (MAX)를 사용하는 불이익이 있습니까?

SQL Server 2005에서는, 예를 들어, 모든 문자 필드 NVARCHAR (MAX)를 만드는 것이 아니라 명시 적으로 길이를 지정하는 불이익이있다 NVARCHAR (255)? (별도로 명백한에서 데이터베이스 수준에서 필드 길이를 제한 할 수없는 것을)

해결법

==============================
1.같은 질문은 MSDN 포럼에 질문을 받았다 :

같은 질문은 MSDN 포럼에 질문을 받았다 :

원래 포스트 (이 훨씬 더 많은 정보)에서 :
==============================
2.그것은 공정한 질문 그리고 그는 분명 그렇다 상태를했다 ...

그것은 공정한 질문 그리고 그는 분명 그렇다 상태를했다 ...

단점은 포함 할 수있다 :

성능에 미치는 영향 쿼리 최적화 프로그램에서 사용하는 필드의 크기는 가장 효율적인 실행 계획을 결정하기

"1. 우주 alloction를 확장하고 데이터베이스의 페이지는 유연합니다. 업데이 트를 사용하여 필드에 정보를 추가 할 때 따라서, 데이터베이스가 새로운 데이터가 더 이상 삽입 이전보다 경우 포인터를 생성해야합니다.이 데이터베이스 파일 것 단편화 = 삭제 인덱스, 갱신 및 삽입에서, 거의 모든 성능을 낮 춥니 다. " 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
==============================
3.때때로 당신은 데이터 유형이있는 데이터에 어떤 의미를 시행합니다.

때때로 당신은 데이터 유형이있는 데이터에 어떤 의미를 시행합니다.

예를 들어 당신이 정말로 20 자, 말, 초과 할 수 없습니다해야하는 열이 말해봐. 당신은 VARCHAR (MAX) 등이 열을 정의하면, 일부 악성 응용 프로그램은로 긴 문자열을 삽입 할 수 당신은 모를 것, 또는 예방의 방법이있다.

응용 프로그램이 문자열의 길이가 나타내는 도메인에 대한 겸손하고 합리적이라는 가정하에, 해당 문자열을 사용하여 다음 번에, 당신은 예측 불가능하고 혼란 결과를 경험하게 될 것입니다.
==============================
4.허용 대답에 제공된 링크에 기초하여,이 나타납니다 :

허용 대답에 제공된 링크에 기초하여,이 나타납니다 :

하나...

결론:

당신은 공간과 액세스 시간을 낭비하지 않습니다 색인 할 수 있습니다 전체 데이터베이스를 통해 "보편적 인 문자열 길이"의 종류를 원하는 경우에, 당신은 NVARCHAR (4000)를 사용할 수 있습니다.

==============================

5.내가 어떤 기사를 확인하고이에서 유용한 테스트 스크립트를 찾을 수 : http://www.sqlservercentral.com/Forums/Topic1480639-1292-1.aspx 그런 다음 NVARCHAR 대 NVARCHAR (4000) (MAX) 대 NVARCHAR (10) 사이의 비교를 변경 지정된 번호를 사용하지만 MAX를 사용할 때 속도 차이를 찾을 수 없습니다. 당신은 직접 테스트 할 수 있습니다. 이 도움을 바랍니다.

내가 어떤 기사를 확인하고이에서 유용한 테스트 스크립트를 찾을 수 : http://www.sqlservercentral.com/Forums/Topic1480639-1292-1.aspx 그런 다음 NVARCHAR 대 NVARCHAR (4000) (MAX) 대 NVARCHAR (10) 사이의 비교를 변경 지정된 번호를 사용하지만 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

==============================
6.또 다른 안전 수준이라고 생각. 완벽하게 유효한 - - 당신은 외래 키 관계없이 테이블을 디자인 할 수 및 전체 비즈니스 계층에 연관된 엔티티의 존재를 확인합니다. 그들은 비즈니스 계층에 경우 뭔가 놨을 다른 제약 수준을 추가하기 때문에, 외래 키는 좋은 디자인 연습 간주됩니다. 같은 필드의 크기 제한에 대한 이동 및 VARCHAR MAX를 사용하지.

또 다른 안전 수준이라고 생각. 완벽하게 유효한 - - 당신은 외래 키 관계없이 테이블을 디자인 할 수 및 전체 비즈니스 계층에 연관된 엔티티의 존재를 확인합니다. 그들은 비즈니스 계층에 경우 뭔가 놨을 다른 제약 수준을 추가하기 때문에, 외래 키는 좋은 디자인 연습 간주됩니다. 같은 필드의 크기 제한에 대한 이동 및 VARCHAR MAX를 사용하지.
==============================
7.최대 또는 텍스트 필드를 사용하지 않는 이유는 온라인 인덱스를 수행 할 수 있다는 것입니다 재 구축 즉, 심지어 SQL Server 엔터프라이즈 버전과로 온 = 재 구축.

최대 또는 텍스트 필드를 사용하지 않는 이유는 온라인 인덱스를 수행 할 수 있다는 것입니다 재 구축 즉, 심지어 SQL Server 엔터프라이즈 버전과로 온 = 재 구축.
==============================
8.내가 찾은 유일한 문제는 우리가 SQL 서버 2005 우리의 응용 프로그램을 개발하고, 하나 개의 인스턴스에서, 우리는 SQL 서버 2000 난 그냥 배운, SQL 서버 2000 VARCHAR 또는에 대한 MAX 옵션처럼하지 않는 하드 방법을 지원해야이었다 NVARCHAR.

내가 찾은 유일한 문제는 우리가 SQL 서버 2005 우리의 응용 프로그램을 개발하고, 하나 개의 인스턴스에서, 우리는 SQL 서버 2000 난 그냥 배운, SQL 서버 2000 VARCHAR 또는에 대한 MAX 옵션처럼하지 않는 하드 방법을 지원해야이었다 NVARCHAR.
==============================
9.이 필드 세트에있을 것입니다 알고 나쁜 아이디어는 예를 들어 10 문자 5 유명한 관광 명소. 나는 길이 될 것입니다 무엇인지 아니었다면 난 단지 최대 사용하는 거라고 생각합니다. 예를 들어 전화 번호는 문자의 특정 숫자보다 더 많은 수 없을 것입니다.

이 필드 세트에있을 것입니다 알고 나쁜 아이디어는 예를 들어 10 문자 5 유명한 관광 명소. 나는 길이 될 것입니다 무엇인지 아니었다면 난 단지 최대 사용하는 거라고 생각합니다. 예를 들어 전화 번호는 문자의 특정 숫자보다 더 많은 수 없을 것입니다.

솔직히 당신이 당신의 테이블의 모든 필드에 대한 대략적인 길이 요구 사항에 대한 확신이 말할 수 있습니까?

나는 확실히 VARCHAR (최대)를 사용하여 생각 하는데요 일부 필드가 though- 나는 당신의 포인트를받을 수 있나요.

흥미롭게도 MSDN의 문서는 매우 잘 요약 :

여기 문제에 대한 흥미로운 토론이있다.
==============================
10.이 기업에서 사용할 수 있도록 데이터베이스 작업은 데이터를 저장하는 것입니다. 데이터가 유용하게 만드는 부분은 의미가 보장된다. 누군가가 자신의 이름이 의미있는 데이터를 보장하지 않습니다에 대한 문자를 무제한으로 입력 할 수 있도록 허용.

이 기업에서 사용할 수 있도록 데이터베이스 작업은 데이터를 저장하는 것입니다. 데이터가 유용하게 만드는 부분은 의미가 보장된다. 누군가가 자신의 이름이 의미있는 데이터를 보장하지 않습니다에 대한 문자를 무제한으로 입력 할 수 있도록 허용.

비즈니스 계층에 이러한 제약을 구축하는 것은 좋은 아이디어이지만, 그 데이터베이스가 그대로 유지됩니다 것을 보장하지 않습니다. 데이터 규칙을 위반되지 않는다는 보장하는 유일한 방법은 데이터베이스에서 가능한 가장 낮은 수준에서 시행하는 것입니다.
==============================
11.한 가지 문제는 SQL Server의 여러 버전 작업에 발생하는 경우 MAX는 항상 작동하지 않을 것입니다. 레거시 DB의 또는 여러 버전을 포함 다른 상황에 작업하는 경우 그래서, 당신은 더 나은 매우주의해야합니다.

한 가지 문제는 SQL Server의 여러 버전 작업에 발생하는 경우 MAX는 항상 작동하지 않을 것입니다. 레거시 DB의 또는 여러 버전을 포함 다른 상황에 작업하는 경우 그래서, 당신은 더 나은 매우주의해야합니다.
==============================
12.위에서 지적 된 바와 같이, 스토리지 및 성능 간의 트레이드 오프는 주로이다. 대부분의 경우 적어도.

위에서 지적 된 바와 같이, 스토리지 및 성능 간의 트레이드 오프는 주로이다. 대부분의 경우 적어도.

그러나, N / VARCHAR (최대) 이상 N / VARCHAR (N)를 선택할 때 고려되어야한다 적어도 하나 개의 다른 요인이있다. 데이터 (예 : 성, 말,로) 색인이 될 것입니다? 맥스 정의가 LOB, MAX로 정의 다음 아무것도 간주되기 때문에 인덱스를 사용할 수 없습니다. 및 인덱스없이 WHERE 절에 조건 등의 데이터와 관련된 모든 조회는 데이터 조회를 위해 얻을 수있는 최악의 성능입니다 전체 테이블 스캔을 강요 할 것입니다.
==============================
13.1) SQL 서버 NVARCHAR (N 대 NVARCHAR (최대)를 처리 할 때 여기서 n 필드에 숫자 고유의 것입니다)) 더 많은 자원 (할당 된 메모리 및 CPU 시간을 활용해야합니다.

1) SQL 서버 NVARCHAR (N 대 NVARCHAR (최대)를 처리 할 때 여기서 n 필드에 숫자 고유의 것입니다)) 더 많은 자원 (할당 된 메모리 및 CPU 시간을 활용해야합니다.

2) 성능에 관해서 이것이 무슨 뜻 이죠?

SQL 서버 2005, 나는 15 NVARCHAR (최대) 열이있는 테이블에서 데이터의 13,000 행을 조회. I는 질의를 반복하고 NVARCHAR (255) 이하로 열을 변경 타이밍.

이전 최적화 쿼리는 2.0858 초 평균. 변경 후 쿼리는 1.90 초 평균에 돌아왔다. 즉, 기본 선택 * 쿼리에 대한 개선의 184 밀리 초에 있었다. 즉 8.8 %의 개선이다.

3) 내 결과는 성능 차이가 있음을 나타내는 몇 가지 다른 기사와 동의에 있습니다. 데이터베이스 쿼리에 따라, 개선의 비율이 다를 수 있습니다. 동시 사용자 또는 매우 많은 기록이 많지 않을 경우, 성능 차이는 당신을 위해 문제가되지 않을 것입니다. 이상의 레코드와 동시 사용자가 증가하지만, 성능 차이는 증가 할 것이다.
==============================
14.나는 문자열을 패딩 및 VARCHAR (최대) 출력을 넣어 UDF를했다. 이 조정되는 열에 대한 적절한 크기로 다시 캐스팅으로 대신 직접 사용 된 경우, 성능은 매우 가난했다. 나는 큰 메모와 함께 임의의 길이로 UDF를 넣는 대신 다시 캐스트에 UDF의 모든 호출자에 작은 크기로 문자열을 의존 끝났다.

나는 문자열을 패딩 및 VARCHAR (최대) 출력을 넣어 UDF를했다. 이 조정되는 열에 대한 적절한 크기로 다시 캐스팅으로 대신 직접 사용 된 경우, 성능은 매우 가난했다. 나는 큰 메모와 함께 임의의 길이로 UDF를 넣는 대신 다시 캐스트에 UDF의 모든 호출자에 작은 크기로 문자열을 의존 끝났다.
==============================
15.흥미있는 링크 : 텍스트를 사용할 수있을 때 왜 VARCHAR를 사용합니까?

흥미있는 링크 : 텍스트를 사용할 수있을 때 왜 VARCHAR를 사용합니까?

성능 분석은 다르지만, "명확성"에 대한 논리가 여전히 유효 그래서, PostgreSQL의와 MySQL에 관하여 : 왜 자신은 항상 시간의 작은 비율 관련이 뭔가에 대해 걱정 힘? 당신이 변수에 이메일 주소를 저장 한 경우, 당신은 '문자열'이 아닌 '80 개 문자로 제한 문자열을'사용하십시오.
==============================
16.레거시 시스템을 지원합니다. 당신이 데이터를 사용하는 시스템을 가지고 있고 특정 길이 될 것으로 예상되고있는 경우, 데이터베이스는 길이를 시행하기에 좋은 장소입니다. 이것은 이상적인 것이 아니라 기존 시스템은 언젠가는 적합하지 않습니다. P =

레거시 시스템을 지원합니다. 당신이 데이터를 사용하는 시스템을 가지고 있고 특정 길이 될 것으로 예상되고있는 경우, 데이터베이스는 길이를 시행하기에 좋은 장소입니다. 이것은 이상적인 것이 아니라 기존 시스템은 언젠가는 적합하지 않습니다. P =
==============================
17.(모든 열에 대한) 행의 모든 데이터가 합리적으로 8000 개 이하의 문자를 취하지 않을 것입니다 경우 데이터 계층에서 디자인이 시행해야한다.

(모든 열에 대한) 행의 모든 데이터가 합리적으로 8000 개 이하의 문자를 취하지 않을 것입니다 경우 데이터 계층에서 디자인이 시행해야한다.

데이터베이스 엔진이 훨씬 BLOB 저장소 중보다 효율적인 유지 전부입니다. 작은 당신이 더 나은 행을 제한 할 수 있습니다. 더 많은 행 당신은 더 나은 페이지에 벼락 공부 할 수 있습니다. 이 적은 페이지에 액세스 할 수 있습니다 더 나은 데이터베이스는 수행.

==============================

18.내 테스트는 선택의 차이가 있음을 보여 주었다.

내 테스트는 선택의 차이가 있음을 보여 주었다.

CREATE TABLE t4000 (a NVARCHAR(4000) NULL);

CREATE TABLE tmax (a NVARCHAR(MAX) NULL);

DECLARE @abc4 NVARCHAR(4000) = N'ABC';

INSERT INTO t4000
SELECT TOP 1000000 @abc4
    FROM
    master.sys.all_columns ac1,
    master.sys.all_columns ac2;

DECLARE @abc NVARCHAR(MAX) = N'ABC';

INSERT INTO tmax
SELECT TOP 1000000 @abc
    FROM
    master.sys.all_columns ac1,
    master.sys.all_columns ac2;

SET STATISTICS TIME ON;
SET STATISTICS IO ON;

SELECT * FROM dbo.t4000;
SELECT * FROM dbo.tmax;

==============================

19.내가 볼 수있는 가장 큰 단점은하자의 당신이이 말을한다는 것입니다 :

내가 볼 수있는 가장 큰 단점은하자의 당신이이 말을한다는 것입니다 :

어느 것이 당신에게 UI에 필요한 데이터에 대한 대부분의 정보를 제공?

이

            CREATE TABLE [dbo].[BusData](
                [ID] [int] IDENTITY(1,1) NOT NULL,
                [RecordId] [nvarchar](MAX) NULL,
                [CompanyName] [nvarchar](MAX) NOT NULL,
                [FirstName] [nvarchar](MAX) NOT NULL,
                [LastName] [nvarchar](MAX) NOT NULL,
                [ADDRESS] [nvarchar](MAX) NOT NULL,
                [CITY] [nvarchar](MAX) NOT NULL,
                [County] [nvarchar](MAX) NOT NULL,
                [STATE] [nvarchar](MAX) NOT NULL,
                [ZIP] [nvarchar](MAX) NOT NULL,
                [PHONE] [nvarchar](MAX) NOT NULL,
                [COUNTRY] [nvarchar](MAX) NOT NULL,
                [NPA] [nvarchar](MAX) NULL,
                [NXX] [nvarchar](MAX) NULL,
                [XXXX] [nvarchar](MAX) NULL,
                [CurrentRecord] [nvarchar](MAX) NULL,
                [TotalCount] [nvarchar](MAX) NULL,
                [Status] [int] NOT NULL,
                [ChangeDate] [datetime] NOT NULL
            ) ON [PRIMARY]

아니면 이거?

            CREATE TABLE [dbo].[BusData](
                [ID] [int] IDENTITY(1,1) NOT NULL,
                [RecordId] [nvarchar](50) NULL,
                [CompanyName] [nvarchar](50) NOT NULL,
                [FirstName] [nvarchar](50) NOT NULL,
                [LastName] [nvarchar](50) NOT NULL,
                [ADDRESS] [nvarchar](50) NOT NULL,
                [CITY] [nvarchar](50) NOT NULL,
                [County] [nvarchar](50) NOT NULL,
                [STATE] [nvarchar](2) NOT NULL,
                [ZIP] [nvarchar](16) NOT NULL,
                [PHONE] [nvarchar](18) NOT NULL,
                [COUNTRY] [nvarchar](50) NOT NULL,
                [NPA] [nvarchar](3) NULL,
                [NXX] [nvarchar](3) NULL,
                [XXXX] [nvarchar](4) NULL,
                [CurrentRecord] [nvarchar](50) NULL,
                [TotalCount] [nvarchar](50) NULL,
                [Status] [int] NOT NULL,
                [ChangeDate] [datetime] NOT NULL
            ) ON [PRIMARY]

==============================
20.한 가지 단점은 예측할 수없는 변수를 주위에 설계되고, 당신은 아마 대신 점진적 행 (들), 페이지 (들)로 구성 내부 SQL Server 데이터 구조의 걸릴 장점으로 무시하고 넓이 (들)이다.

한 가지 단점은 예측할 수없는 변수를 주위에 설계되고, 당신은 아마 대신 점진적 행 (들), 페이지 (들)로 구성 내부 SQL Server 데이터 구조의 걸릴 장점으로 무시하고 넓이 (들)이다.

어느 날 C에서 데이터 구조의 정렬에 대해 생각하고, 정렬 인식하고하는 것은 일반적으로 좋은 것이다 (TM)를 것으로 간주됩니다 수 있습니다. 비슷한 생각, 다른 문맥.

페이지 및 익스텐트에 대한 MSDN 페이지

행 오버플로 데이터에 대한 MSDN 페이지
==============================
21.데이터베이스가 작은 경우는 실제 문제를 일으킬 않을 수 있지만 이것은 성능 문제가 발생합니다. 각 레코드는 하드 드라이브에 더 많은 공간을 차지하고 한 번에 기록의 많은 통해 검색하는 경우 데이터베이스는 디스크의 이상의 섹터를 읽을해야합니다. 예를 들어, 작은 기록은 섹터 50에 맞게 수있는 큰 기록 당신은 큰 기록을 사용하여 디스크에서 많은 데이터로 10 회를 읽을 필요 것 5. 적합 할 수있다.

데이터베이스가 작은 경우는 실제 문제를 일으킬 않을 수 있지만 이것은 성능 문제가 발생합니다. 각 레코드는 하드 드라이브에 더 많은 공간을 차지하고 한 번에 기록의 많은 통해 검색하는 경우 데이터베이스는 디스크의 이상의 섹터를 읽을해야합니다. 예를 들어, 작은 기록은 섹터 50에 맞게 수있는 큰 기록 당신은 큰 기록을 사용하여 디스크에서 많은 데이터로 10 회를 읽을 필요 것 5. 적합 할 수있다.
==============================
22.더 이상 컨트롤 할 방법을 다양한 예측할 수 없을 것 같이 열심히 화면 디자인을 만들 것입니다.

더 이상 컨트롤 할 방법을 다양한 예측할 수 없을 것 같이 열심히 화면 디자인을 만들 것입니다.

from https://stackoverflow.com/questions/148398/are-there-any-disadvantages-to-always-using-nvarcharmax by cc-by-sa and MIT license

'SQL' 카테고리의 다른 글

[SQL] 저장 프로 시저에서 "SET XACT_ABORT ON"을 사용의 이점은 무엇입니까? (0)	2020.03.21
[SQL] 단지 null이 아닌 값을 선택 MYSQL (0)	2020.03.21
[SQL] 다른 테이블에서 추출한 테이블 레코드에 INSERT 작업을 수행하는 방법 (0)	2020.03.21
[SQL] 어떻게 ID를 사용하여 여러 SQL 테이블을 가입 할 수 있습니까? (0)	2020.03.21
[SQL] 필드 단어가 포함 된 SQL SELECT (0)	2020.03.21

복붙노트

[SQL] 항상 NVARCHAR (MAX)를 사용하는 불이익이 있습니까?

항상 NVARCHAR (MAX)를 사용하는 불이익이 있습니까?

해결법

1.같은 질문은 MSDN 포럼에 질문을 받았다 :

2.그것은 공정한 질문 그리고 그는 분명 그렇다 상태를했다 ...

3.때때로 당신은 데이터 유형이있는 데이터에 어떤 의미를 시행합니다.

4.허용 대답에 제공된 링크에 기초하여,이 나타납니다 :

7.최대 또는 텍스트 필드를 사용하지 않는 이유는 온라인 인덱스를 수행 할 수 있다는 것입니다 재 구축 즉, 심지어 SQL Server 엔터프라이즈 버전과로 온 = 재 구축.

11.한 가지 문제는 SQL Server의 여러 버전 작업에 발생하는 경우 MAX는 항상 작동하지 않을 것입니다. 레거시 DB의 또는 여러 버전을 포함 다른 상황에 작업하는 경우 그래서, 당신은 더 나은 매우주의해야합니다.

12.위에서 지적 된 바와 같이, 스토리지 및 성능 간의 트레이드 오프는 주로이다. 대부분의 경우 적어도.

13.1) SQL 서버 NVARCHAR (N 대 NVARCHAR (최대)를 처리 할 때 여기서 n 필드에 숫자 고유의 것입니다)) 더 많은 자원 (할당 된 메모리 및 CPU 시간을 활용해야합니다.

15.흥미있는 링크 : 텍스트를 사용할 수있을 때 왜 VARCHAR를 사용합니까?

17.(모든 열에 대한) 행의 모든 데이터가 합리적으로 8000 개 이하의 문자를 취하지 않을 것입니다 경우 데이터 계층에서 디자인이 시행해야한다.

18.내 테스트는 선택의 차이가 있음을 보여 주었다.

19.내가 볼 수있는 가장 큰 단점은하자의 당신이이 말을한다는 것입니다 :

20.한 가지 단점은 예측할 수없는 변수를 주위에 설계되고, 당신은 아마 대신 점진적 행 (들), 페이지 (들)로 구성 내부 SQL Server 데이터 구조의 걸릴 장점으로 무시하고 넓이 (들)이다.

22.더 이상 컨트롤 할 방법을 다양한 예측할 수 없을 것 같이 열심히 화면 디자인을 만들 것입니다.

'SQL' 카테고리의 다른 글

티스토리툴바

항상 NVARCHAR (MAX)를 사용하는 불이익이 있습니까?

해결법

1.같은 질문은 MSDN 포럼에 질문을 받았다 :

2.그것은 공정한 질문 그리고 그는 분명 그렇다 상태를했다 ...

3.때때로 당신은 데이터 유형이있는 데이터에 어떤 의미를 시행합니다.

4.허용 대답에 제공된 링크에 기초하여,이 나타납니다 :

7.최대 또는 텍스트 필드를 사용하지 않는 이유는 온라인 인덱스를 수행 할 수 있다는 것입니다 재 구축 즉, 심지어 SQL Server 엔터프라이즈 버전과로 온 = 재 구축.

11.한 가지 문제는 SQL Server의 여러 버전 작업에 발생하는 경우 MAX는 항상 작동하지 않을 것입니다. 레거시 DB의 또는 여러 버전을 포함 다른 상황에 작업하는 경우 그래서, 당신은 더 나은 매우주의해야합니다.

12.위에서 지적 된 바와 같이, 스토리지 및 성능 간의 트레이드 오프는 주로이다. 대부분의 경우 적어도.

13.1) SQL 서버 NVARCHAR (N 대 NVARCHAR (최대)를 처리 할 때 여기서 n 필드에 숫자 고유의 것입니다)) 더 많은 자원 (할당 된 메모리 및 CPU 시간을 활용해야합니다.

15.흥미있는 링크 : 텍스트를 사용할 수있을 때 왜 VARCHAR를 사용합니까?

17.(모든 열에 대한) 행의 모든 ​​데이터가 합리적으로 8000 개 이하의 문자를 취하지 않을 것입니다 경우 데이터 계층에서 디자인이 시행해야한다.

18.내 테스트는 선택의 차이가 있음을 보여 주었다.

19.내가 볼 수있는 가장 큰 단점은하자의 당신이이 말을한다는 것입니다 :

20.한 가지 단점은 예측할 수없는 변수를 주위에 설계되고, 당신은 아마 대신 점진적 행 (들), 페이지 (들)로 구성 내부 SQL Server 데이터 구조의 걸릴 장점으로 무시하고 넓이 (들)이다.

22.더 이상 컨트롤 할 방법을 다양한 예측할 수 없을 것 같이 열심히 화면 디자인을 만들 것입니다.

'SQL' 카테고리의 다른 글

티스토리툴바

17.(모든 열에 대한) 행의 모든 데이터가 합리적으로 8000 개 이하의 문자를 취하지 않을 것입니다 경우 데이터 계층에서 디자인이 시행해야한다.