Início / dba / Perguntas / 6987
Accepted
Thomas Stringer
Asked: 2011-10-20 18:47:56 +0800 CST

INT ou CHAR para um campo de tipo

  • 772

Qual é o melhor design para uma tabela, um Typecampo que é de intou char(1)? Em outras palavras, dado este esquema:

create table Car
(
    Name varchar(100) not null,
    Description varchar(100) not null,
    VehType .... not null
)

É mais eficiente (em termos de desempenho) VehTypeser um intou um char(1)? Digamos que você tenha cinco tipos de carros, você deve usar os valores de incremento 0 -> 4 ou caracteres para os tipos (digamos; 'v', 's', 'c', 't', 'm')?

Se for mais do que isso, eu usaria uma tabela Type separada e teria um relacionamento de chave estrangeira, mas não vejo necessidade disso.

Percebo que a sys.objectsexibição do catálogo usa um caractere para o typecampo. Existe uma razão para isso? Estou apenas agarrando o ar aqui, e é o que quer que eu esteja mais confortável?

sql-server database-design

2 respostas

  1. Best Answer

    Você normalmente usaria tinyint, que também tem 1 byte

    • char(1) será um pouco mais lento porque a comparação usa collation

    • confusão: o que é S: SUV ou Saloon ou Sedan ou Sports?

    • usar uma letra limita você à medida que adiciona mais tipos. Veja o último ponto.

    • todo sistema que vi tem mais de um cliente, por exemplo, relatórios. A lógica de mudar V, S para "Van", "SUV" etc precisará ser repetida. Usar uma tabela de pesquisa significa que é um simples JOIN

    • extensibilidade: adicione mais um tipo ("F" para " Carro voador "), você pode uma linha para uma tabela de pesquisa ou alterar muitos códigos e restrições. E seu código cliente também porque tem que saber o que são V,S,F etc

    • manutenção: a lógica está em 3 locais: restrição do banco de dados, código do banco de dados e código do cliente. Com uma pesquisa e chave estrangeira, pode estar em um só lugar

    O lado positivo de usar uma única letra... er, não vejo nenhuma

    Nota: há uma pergunta relacionada ao MySQL sobre Enums . A recomendação é usar uma tabela de consulta lá também.

    • 19

  2. Apenas como um complemento à resposta de great gbn .

    Talvez você possa criar algo assim:

    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

    Portanto, você pode fazer o que quiser com seu enum enquanto mantém a integridade relacional (usando uma chave estrangeira). Com a codecoluna, você pode usar seus códigos de caracteres à vontade, para que fique documentado no banco de dados (e você pode extrair as informações do código diretamente do banco de dados, sem uma transformação complicada no código do aplicativo para uma integração de sistemas).

    • 3

relate perguntas