테이블, 또는 Type필드에 가장 적합한 디자인은 무엇입니까 ? 다시 말해,이 스키마가 주어지면 :intchar(1)
create table Car
(
Name varchar(100) not null,
Description varchar(100) not null,
VehType .... not null
)
하기에보다 효율적으로 (현명한 성능)가 VehType할 수 int또는은 char(1)? 5 가지 유형의 자동차가 있다고 가정합니다. 증가 값 0-> 4 또는 유형의 문자 (예 : 'v', 's', 'c', 't', 'm')를 사용해야합니까?
그 이상이면 별도의 Type 테이블을 사용하고 외래 키 관계를 갖지만 그 필요성이 보이지 않습니다.
나는 것을 알 수 sys.objects카탈로그 뷰는위한 문자 사용 type필드. 그 이유가 있습니까? 나는 단지 여기에서 얇은 공기를 움켜 쥐고 있는가?
답변:
일반적으로 1 바이트 인 tinyint를 사용합니다.
사용하여 데이터 정렬을 비교하기 때문에 char (1)이 약간 느려집니다.
혼란 : S : SUV 또는 Saloon 또는 Sedan 또는 Sports는 무엇입니까?
문자를 사용하면 더 많은 유형을 추가 할 때 제한됩니다. 마지막 요점을 참조하십시오.
내가 본 모든 시스템에는보고와 같은 하나 이상의 클라이언트가 있습니다. V, S를 "Van", "SUV"등으로 변경하는 논리는 반복해야합니다. 룩업 테이블을 사용한다는 것은 간단한 가입입니다.
확장 성 : 룩업 테이블에 하나의 행을 추가하거나 많은 코드와 제약 조건을 변경할 수있는 하나 이상의 유형 ( " Flying Car "의 경우 "F")을 추가하십시오 . 그리고 클라이언트 코드도 V, S, F 등이 무엇인지 알아야하기 때문에
유지 관리 : 논리는 데이터베이스 제약 조건, 데이터베이스 코드 및 클라이언트 코드의 세 위치에 있습니다. 조회 및 외래 키를 사용하면 한 곳에있을 수 있습니다.
하나의 문자를 사용하는 것의 장점은 무엇입니까?
위대한 gbn의 답변을 보완하는 것과 같습니다 .
아마도 당신은 그런 것을 만들 수 있습니다 :
create table dbo.VehicleType
(
VehicleTypeId int not null primary key,
Name varchar(50) not null,
Code char(3) null
)
go
create table Car
(
Name varchar(100) not null,
Description varchar(100) not null,
VehTypeId int not null ,
foreign key FKTypeOfCar(VehTypeId) referenctes dbo.VehicleType (VehicleTypeId)
)
go 따라서 관계형 무결성을 유지하면서 외래 키를 사용하여 열거 형으로 원하는대로 할 수 있습니다. 으로 code는 데이터베이스에 기록 될 수 있도록 열 당신이 마음대로 당신의 문자 코드를 사용할 수 있습니다 (그리고 당신은 시스템 통합을위한 응용 프로그램 코드에 복잡한 변환하지 않고, DB에서 직접 코드 정보를 추출 할 수 있습니다).
null코드 를 허용 하시겠습니까?