기본 키 값 문자 대신 int 값 1을 사용합니다.

Question

흠 나는 데이터베이스 아키텍처에 대해 많이 알지는 못하지만 CTO의 마음에는 무엇이 있는지 이해하지 못한다. 그러나 문자를 우리가 사용하는 모든 테이블의 기본 키. 그러나 기본 키는 여전히 다음과 같습니다. -> 1,2,3 ... 등 숫자입니다. 합성용 PK에 integer + auto_increment를 사용합니다.

CTO는 PK에 LIKE 조건을 사용하여 쿼리를 발행 할 수 없다고 말합니다.

1. 특히 PK가 숫자 인 경우 PK 문자를 사용하는 것이 좋습니까?
2. PK와 같은 조건을 사용하는 것이 맞습니까?

PS - 그래서 대신 테이블에서 가장 큰 값을 가져옵니다 그는 1을 더한 후 그 문자열 다음 저장 그것으로 그 값을 변환 자동 증가/트리거, 시퀀스 CTO 문제를 선택 쿼리.

감사합니다. 하지만 그에게 재앙이 될 것이라고 확신시켜야합니다. 나는 (이 경우 캐릭터 4 PK는) 나쁜 생각이라는 것을 가르쳤다. 그는 논쟁의 대상이 ...
1. 문자 PK는 많은 공간을 차지하지 않습니다. 당신이
"select * from employee where name like 'somename'
및 Select * from employee where id = 6
같은 것을 발행해야하기 때문에
2. 데이터베이스 쿼리 최적화는 INT 형 PK 를 사용하는 경우 쿼리를 다시 읽어해야합니다.
where 절이 변경되기 때문입니다.
우리가 사용하는 것이 강력하다고 주장한 것
"select * from employee where @columnName like @value"
그는 이렇게 말하면 쿼리 최적화 프로그램이 더 잘 실행될 것이라고 말했습니다.

그에게 마음을 바꾸기위한 유효한 이유를 증명하거나 줄 수있는 방법은 무엇입니까?

감사합니다.)

Answer 1

CTO가 그 결정에 실수를 범한 이유는 많습니다. 내가 몇 가지를 커버하자 : 당신이 언급했듯이, 새로운 자동 증가 PRIMARY KEY를 생성하는 추가 단계를 수행해야

1. . 이는 컴퓨팅 비용이며 향후 어느 시점에서 일관성있게 적용되지 않을 가능성을 높입니다.

2. 문자가 4자를 초과하면 문자의 디스크 공간이 더 많이 소모됩니다. 즉, 12345는 "12345"보다 저장하기가 훨씬 쌉니다. , 1, 10 :

문자 : 당신은 (일부 RDBM의 기본값입니다) 당신의 기본 키에 클러스터 된 인덱스를 사용하는 경우

는 문자를 정렬하는 정수를 정렬하는 것보다 완전히 다른 101, 11,12,13,14,15 ... 숫자 : 1,2,3,4 ...

최대 숫자를 문자로 삽입하는 경우 색인을 파쇄하는 것입니다. . 극복 할 수없는 문제는 아니지만 정리할 컴퓨팅 전력을 낭비합니다.

PRMMARY KEY에서 LIKE를 사용하는 것에 대한 두 번째 질문에 대해 나는 그런 생각을 할 수 없다고 생각합니다. LIKE 권한이 필요한 경우 일반적으로 PRIMARY KEY로 사용되는 열에 어떤 종류의 중요성을 지정했기 때문에 이는 최종 사용자에게 공개해야합니다. 그렇다면 대용량 자동 증분 숫자 기본 키를 사용하고 사용자에게 몇 가지 ID 형태를 노출합니다.

Answer 2

1 : 예, 괜찮습니다. 차 안에서도 항상 10 마일을 운전하는 것이 좋습니다. 차가 고장 나지 않을 것입니다. Chars (또는 varchars)는 비교할 때 속도가 느리므로 동일한 성능을 위해 더 큰 예산을 요구합니다. 그들은 공간을 낭비하고 천천히 움직입니다. 여기있는 유일한 분별있는 일을하는 것이 좋습니다 - 바보가 아닌 다른 사람과 일자리를 찾으십시오.

2 확실하지 않습니다. 보세요, 여기 문제는 - 당신이 사용하지 못하는 것일 가능성이 가장 높습니다. 마찬가지로 : 데이터베이스가 허용하지 않습니다. 나는 정말로 결코 시도하지 않고 있었다 - 나는 또한 단지 그것이 차를 손상시키는 지 알기 위해 시간당 100 마일의 콘크리트 블록을 치려고하지 않는다. 이것은 단지별로 의미가 없습니다.

귀하의 CTO는 분명히 휴일을 보내고 책을 읽어야합니다. 아마 누군가 CTO와 얘기하고 CTO에게 바보가된다.

합성 키 (한 필드) 기본 키에 대한 인수가 있지만 데이터베이스와 함께 25 년 동안 DBase 또는 Cobol 외부에서 수행하지는 않습니다. 그것은 서사시적인 무지이다. 뾰족한 상사.

Answer 3

글쎄, 당신은 이 (가정 SQL 2008 R2 +) 같은 것을 할 수있는 :

create table dbo.keep_the_peace (
    pk as right(replicate('0',10)+convert(varchar(10),pk_generator),10) persisted not null 
, pk_generator int not null identity(1,1) 
, name nvarchar(128) not null 
, constraint pk_keep_the_peace primary key nonclustered (pk) 
, constraint uc_keep_the_peace unique clustered (pk_generator) 
) 
go 

insert dbo.keep_the_peace (name) values ('Hello') 
insert dbo.keep_the_peace (name) values ('World') 

select * from dbo.keep_the_peace 

장점 :

1. pk은 VARCHAR입니다, CTO는 LIKE
2. pk이 자동 생성됩니다 사용할 수 있습니다 , 삽입시 테이블 다시 쿼리 할 필요가 없음
3. pk은 제로 패딩 덕분에 올바른 순서로 정렬됩니다.
4. pk_generator은 외래 키 제약 조건에서 사용할 수 있습니다. 참조 당 6 바이트를 절약 할 수 있지만 CTO는 여전히 pk에 가입하여 올바른 결과를 얻을 수 있습니다.
   1. pk + pk_generator 사용을 필요 이상으로 10 개의 행 당 14 바이트 : keep_the_peace에
   2. 클러스터되지 않은 인덱스는 마른 클러스터링 키 (pk_generator)

   단점을 즐길 수 있습니다.

5. pk_keep_the_peace은 행당 14 바이트를 필요로하는 것보다 14 바이트 많이 사용합니다.(LOL)

EDIT 그가 강력하게 우리가이었다 사용할 것을 주장 무엇

그는이 방법을 말했다 쿼리 최적화 "@value 같은 @columnName 직원 SELECT * FROM"같은 더 잘 달릴거야.

• 그러한 구문은 없다 : 열 이름없이 동적 SQL 변수화 될 수 없다.
• 이러한 이점이 없습니다. 열 이름이 변경 될 때마다 새 실행 계획이 생성됩니다.

WHERE 절의 열이 변경되면 쿼리가 다시 컴파일됩니다. 이것을 피할 방법이 없습니다. 열은 다르게 인덱싱 될 수 있습니다.

select * from employee where name like 'somename%' 

은 비를 넣어 :

select * from employee where id = 6 

을이 비싼 테이블 스캔을 필요로하는 반면 :

예를 들어, id에 클러스터 된 인덱스로,이 추구 클러스터 된 인덱스로 실행됩니다 클러스터 된 인덱스는 name이고 동일한 쿼리의 경우보다 효율적인 인덱스 찾기 + 책갈피 조회 (일반적으로)를 얻습니다.

INT 대 CHAR는 아무 관계가 없습니다. 아무것도. 문자 키는 풋 프린트 (일반적으로)가 더 크며 I/O 처리량을 크게 줄입니다. 그러나 이러한 바닐라 쿼리의 성능은 데이터 유형보다 훨씬 더 많은 색인 생성에 달려 있습니다.