型フィールドのINTまたはCHAR

テーブルまたは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、サルーン、セダン、スポーツとは何ですか？

• 文字を使用すると、タイプを追加するときに制限されます。最後のポイントを参照してください。

• 私が見たすべてのシステムには、レポートなど、複数のクライアントがあります。V、Sを「Van」、「SUV」などに変更するロジックを繰り返す必要があります。ルックアップテーブルを使用すると、単純なJOINになります

• 拡張性：ルックアップテーブルに1つの行を追加したり、多くのコードや制約を変更したりするために、もう1つのタイプ（「空飛ぶ車」の「F」）を追加します。クライアントコードもV、S、Fなどが何であるかを知る必要があるため

• メンテナンス：ロジックは、データベース制約、データベースコード、クライアントコードの3つの場所にあります。ルックアップと外部キーを使用すると、1つの場所に配置できます

単一の文字を使用するプラス面...えー、何も表示されません

注：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 

したがって、（外部キーを使用して）リレーショナル整合性を維持しながら、enumを自由に使用できます。このcode列を使用すると、文字コードを自由に使用できるため、データベースに文書化されます（システム統合のためのアプリケーションコードの複雑な変換なしに、DBからコード情報を直接抽出できます）。