6

列挙型をデータベースに格納するには、文字列または整数の2つの方法があります。

列挙型(、、など)を文字列として保存するsex = {male,female}account_type = {regular,pro,admin}、読みやすくなりますが、整数よりも多くのスペースが必要になります。

一方、整数では、データベースに列挙型をマッピングし、データベースから列挙型をマッピングする必要があります。利点として、大文字と小文字の区別はデータベースの外部で整数で処理されます。

両方にインデックスが付けられていると仮定すると、整数変換は一般的に価値がありますか?整数でのルックアップはどれくらい高速ですか?

おそらく、具体的な例が物事を視覚化するのに役立つ可能性があります。100,000ユーザーのデータベースで上記のaccount_typeを取り上げましょう。

文字列列挙型

8ビット固定長CHAR型を想定

7*100000*8/8 = 700000 bytes

整数列挙型

8ビットのTINYINT整数を想定

100000*8/8 = 400000 bytes

サイズは整数列挙型でほぼ半分のようです。また、インデックスを考慮する必要があります。

4

4 に答える 4

3

答えは、ご想像のとおり、状況によって異なります。

データベースが大きいほど、ディスクだけでなくネットワークIOと計算においてもスペースを大幅に節約できます。

個人的には、(MySQLのように)列挙用の直接DBサポートがない限り、テキスト値の代わりに整数を格納します。

于 2011-07-18T11:13:25.607 に答える
1

データベースのサイズが問題になる場合、intはより少ないメモリを使用します。

コードレイヤーを経由せずにデータベースから直接値を返すかどうかによって異なります(たとえば、何らかの形式の変換)。その場合は、データベースに文字列値が必要になります(ただし、関連するテーブルにルックアップとして格納できます)。

于 2011-07-18T11:15:42.137 に答える
0

変換を行うアプリケーションを介してではなく、人間が DB を見るかどうかという疑問が常にあります。なんらかの理由で DB を見ている場合は、テキストの方が適しています。これは、列挙型変換を確認するためにコードにアクセスできない DBA がいる場合に特に当てはまります。

格納されたデータのサイズがより重要な場合は、int に変換することをお勧めします。しかし、この改善されたスペースでは、読みやすさが失われます。それは、何が最も重要な要素であるかによって異なります。

もちろん、SProcs や Views などを含めて、格納された整数データを調べて文字列値に変換することもできます。これは、2 つのバランスをとる必要がある場合に適しています。

しかし、オデッドが言ったように、単純な答えはありません。すべての状況はわずかに異なります。

于 2011-07-18T11:18:44.167 に答える
0

実際には、おそらくやりたいことは、データベースにマッピング テーブルを作成することです。
これにより、多くの処理が行わ
れます。1) 通常どおり Id 列を割り当ててから、適切な列に外部キーを割り当てます。これにより、無意味な値が挿入されるのを防ぎます。これは、正規化の問題にも対処します。
2) マッピング テーブルを使用すると、ビューを使用してデータベースのみの選択を構築できます。これは、必要なテキスト文字列の id 値を単に交換するだけです。3) マッピング テーブルを使用すると、国際化の問題に対処することも容易になります (注: これは、よりシンプル
になる という意味ではありません)。このためにテーブルを設定する方法は次のとおりです。

Gender_Mapping
Id | Enum_Mapped_Value | DBA_Readable_Description

Gender_Description
Id | Gender_Mapping_Id | Language_Id | Language_Specific_Description

検索の問題については、一意(Enum_Mapped_Value)(Gender_Mapping_Id, Language_Id)ある必要があります (または、少なくともビューから一意に返されます)。
Enum_Mapped_Value列挙型をデータベースにマップするために使用される文字コード(おそらく5文字?)である必要があります。序数値または列挙型自体の名前を使用しないでください。コンストラクターによって割り当てられた内部値を使用してください。そうしないと、将来の開発者が列挙型を並べ替えたり、名前を変更したりする可能性がありますが、内部値はそのままにしておく可能性がはるかに高くなります。複数の言語を扱う予定がある場合は、何らかのテーブル
Language_Idへの外部キーとしてマップする必要があります。Language_Mapping

于 2011-07-18T18:37:30.897 に答える