类型字段的INT或CHAR

什么是一个表，一个最好的设计Type是现场int还是char(1)？换句话说，给定此架构：

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

VehType成为an int或a 更有效（在性能方面更明智）char(1)？假设您有五种类型的汽车，应该使用递增值0-> 4还是类型的字符（例如“ v”，“ s”，“ c”，“ t”，“ m”）？

如果不止如此，我将使用单独的Type表并具有外键关系，但我认为没有必要。

我注意到sys.objects目录视图使用字符作为type字段。有什么理由吗？我是不是在这里捉襟见肘，是否更适合我？

您通常也使用1字节的tinyint

• char（1）会稍微慢一些，因为比较使用排序规则

• 困惑：什么是S：SUV或Saloon或Sedan或Sports？

• 使用字母限制您添加更多类型。见最后一点。

• 我见过的每个系统都有一个以上的客户端，例如报告。将V，S更改为“ Van”，“ SUV”等的逻辑将需要重复。使用查找表意味着它是一个简单的JOIN

• 可扩展性：再添加一种类型（“ Flying car ”为“ F” ），您可以将一行添加到查找表中或更改许多代码和约束。还有您的客户端代码，因为它必须知道什么是V，S，F等

• 维护：逻辑在3个地方：数据库约束，数据库代码和客户端代码。通过查找和外键，它可以放在一个地方

从使用一个字母的好处来看...呃，看不到任何

注意：还有一个有关Enums的MySQL相关问题。建议也在那里使用查找表。

作为对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中提取代码信息，而无需对应用程序代码进行复杂的系统集成转换）。