私は不動産のリストを持つテーブルがあります。すべてのリスティングは、「販売用」または「レンタル用」のいずれかになります。したがって、私は 'For sale'を0に、 'Rent for'を1にマッピングし、INTとしてデータベースに格納することができます。しかし、CHAR型のフィールドに 'sale'/'rent'として格納すると、はるかに説明的になります。または、0と1を2つの定数FOR_SALEとFOR_RENTにマップすることができます。または、文字 'S'と 'R'を使用します。そのようなプロパティの1つに対するオプションの総数が非常に少ないという条件で、そのようなプロパティをデータベースに格納するためのベストプラクティスは何ですか。DBレコードの整数型と文字型のレコードのプロパティ
あなたは、char（オプションの数に応じて）（1）またはint型を使用すると、一定の文字列に、あなたがスペースを節約できますし、文字列を簡単に設定可能になります。この方法で値をマッピングする必要があります将来的には
私はいつも、ほんの僅かのレコードしか持たない単純なルックアップテーブルのものを含め、どんなidでもintを使うでしょう。より一貫性があり、多くのレコードがない場合は、スペースを無駄にすることもありません。 – GolezTrol
PostgreSQLとMySQLサポートenumerated typesこれはあなたが探しているようなものです。列挙型の問題は、データベースの移植性だけです。たとえば、Oracleでは列挙型がないため、代わりにCHARを使用する必要があります。たとえば、PostgreSQLに設定している場合、その機能を利用しない理由はありません。データベースの移植性が必要な場合は、CHAR（1）またはNUMBER（1）を使用するのが最も効率的です。
更新：他の応答が述べたように、変更されないブール値を持つルックアップテーブルを外部キーで使用することができます。これは不要な複雑さを招きます。特に、ORMで追加のクラスを作成する必要があると考えるとき。しかし、その列/変数の値の範囲が変更されることが予想される場合は、ルックアップテーブルを使用することが最善の方法です。
私はその属性をリストにintとして格納し、あなたの説明を追加できるルックアップテーブルの外部キーにします。
列挙型とは対照的に、別々のルックアップテーブルにそれらを持つ利点は、プログラムのクエリでルックアップ値をより簡単に使用できることです。 – GolezTrol
私はちょうどそのような単純な事のためにchar(1)を使用したいと思います。私はまたそれにCHECK制約（利用可能な場合）を叩いて、健全性検査のいくつかの尺度を与えます。 2つの値しか持たないものにテーブルを追加すると、ペンダント的に正しい場合でも少し無意味です。また、列内のSまたはRは、手作業でデータベース内でデバッグまたは操作するときに役に立ちます。1または6はほとんど意味がありません。
もちろん、値があり、それらを表現するために分かりやすいニーモニック文字を思いつくことができない場合は、「intとFK」アプローチが理にかなっています。
必要になった場合は、char(1)から「intとFK」に簡単に変更できます。
可能性はありません販売中であり、同時に賃貸料はありますか？ – Adam
@adam、これは私が知っている不動産業者によればよくあります。 – HLGEM
データベースシステム？ – DeaconDesperado