GUID : VARCHAR (36)에 비해 고유 식별자

나는 VARCHAR (36) 데이터 형식으로 GUID 값을 저장하는 기존 데이터베이스와 함께 일하고 있어요 :GUID : VARCHAR (36)에 비해 고유 식별자

CREATE TABLE T_Rows (
    RowID VARCHAR(36) NOT NULL PRIMARY KEY, 
    RowValue INT   NOT NULL 
) 

INSERT T_Rows (RowID, RowValue) VALUES (NEWID(), 1)

내가 생각 것이라는 고유 식별자로 GUID를 저장하는 것 크기가 36에 비해 16 바이트이기 때문에 바람직합니다.

GUID를 varchar로 저장하면 어떤 이점이 있습니까?

출처

2010-08-19 8kb

나는 그것을 심각하게 의심합니다! –

아마도 당신이 SELECT 문에서 '읽을 수있다'는 사실 (아마도 Uniqueidentifier를 표시 가능하게 만들기 위해 select에서 함수를 사용할 수 있다고 생각하지는 않지만).

테이블이 큰 경우 행당 20 바이트를 절약하는 것이 좋습니다.

출처

2010-08-19 23:24:48

당신은 그것보다 더 많은 것을 얻을 것입니다, 이것은 PK입니다. 그래서 어떤 자식 테이블이라도 비용 절감 효과가 있습니다. 테이블에 다른 인덱스가 있고이 인덱스가 클러스터 된 인덱스 인 경우 모든 인덱스 (및 속도는 테스트 할 수 있지만 테스트해야 함)의 크기는 더 작아집니다. 물론 여러 가지 이유에서 INT는 PK로 더 좋지만 레거시 데이터베이스에서는 커다란 변화입니다. – HLGEM

왜 entity-framework는 GUID에'nvarchar (128)'을 사용합니까? 'uniqueidentifier'를 위해 그것을 바꿀 수 있을까요? – Zapnologica

레거시 데이터베이스가 디자인 상 결함이있는 경우가 많습니다. GUID가 16 바이트이기 때문에 데이터베이스에서 16 바이트를 차지할 수도 있습니다. 엔트리 당 20 바이트를 얻을 수 있습니다.

출처

2010-08-19 23:26:02 Aardvark

UNIQUEIDENTIFIER이 SQL Server 2000에 추가되었으므로이 응용 프로그램은 원래 지원되지 않는 SQL Server 7 용으로 작성된 것일 수 있습니다. 하지만 그 ... 물론, 단지 추측

나는 다음과 같은 여러 가지 이유로 고유 식별자와 함께 갈 것

출처

2010-08-19 23:26:24

는 공간을 적게 걸릴 것입니다; 고유하므로 복제 할 수 없습니다. 비교 및 특수한 성능 관련 문제뿐만 아니라 고유 한 기본값 등을 얻기 쉽기 때문에 훨씬 편리합니다.

아주 특별한 이유로 varchar를 사용해야하는 경우가 아니라면 uniqueidentifier를 사용합니다.

출처

2010-08-19 23:31:52 MSI

만약 내가 추가 할 수 있습니다. 또한 연합 데이터베이스로 작업 할 때 더 좋습니다. 나는 명시된대로 guids 갈 것입니다. – code5

데이터베이스가 Oracle 인 경우 이전 버전의 Oracle (9)에서 원시 데이터 인덱스의 성능은 varchar (36) 필드를 인덱싱하는 것보다 훨씬 어려울 수 있습니다. 다행스럽게도 Oracle 10 및 11에서 변경되었습니다.

출처

2010-09-09 12:14:08 massimogentilini

GUID : VARCHAR (36)에 비해 고유 식별자

답변

관련 문제