古典的なデータベーステーブルの設計は、IDフィールドINT32自動インクリメントをもたらすtableId int index(1,1) not nullを含むであろう。CHAR（4）のような主キー
しかし、これらの数字にいくつかの意味を与えるために有用であろう、と私は人々がenumerablesを含むテーブルのためのCHAR（4）フィールドを使用する方法についてどう思うか知りたいと思いました。
具体的に私のようなデータを持っていたユーザーロールテーブルを考えていました。
"admn" - "Administrator"
"edit" - "Editor".
私はこのコードを自分のコードで参照することができました。
更新
それは管理者が使用する場合は、同期/更新する必要がint型ですUser.IsInRole（「管理者」）ではなくUser.IsInRole（UserRoles.Admin）を参照するコードを書くより理にかなっていますデータベースを再構築します。
私はいつもテーブルにサロゲート主キーを使用する傾向があります。 つまり、ビジネスドメインで意味を持たないキーです。主キーは、この場合、主キーとして「ADMN」を使用する利点は何だろう...
データベースによって要求されたデータの単なる行政の作品ですか！
ハードコード=>データベース参照は常に悪い考えです！ （アプリケーション開始前に設定する場合を除いて）
横：admn =>管理者からのマッピングを実際にデータベースで行う必要がありますか？
そして、あなたは唯一の23^4-（キーワード）LATIN 23charアルファベットとvarchar4とエントリを格納することができます。
「ハードコーディングされた」エントリがアプリケーション内に存在する必要があります。それ以外の場合、アプリとDBの間に接続はありません。 – paxdiablo
接続は、規約に従って透明にすることができます。 SpringSecurity/Acegiを見てください。 "接続"は疎結合（サロゲートキー=>マッピングエントリ）です。アプリの登録方法は規約によります。 –
（データに関連付けられていない）IDフィールドは、代理キーと呼ばれます。彼らには長所と短所があります。それらのリストはthis Wikipedia articleにあります。個人的に私は人々がそれらを酷使し、正しく覚える方法を忘れてしまった（または学んだことがない）と感じている。normalise a database structure。
正規化はうまく設計することができます。 「現実の世界」には、バージョン管理/アーカイブなどの問題があります。あなたがしていることを知っているならば、冗長性は悪いことではありません。 Star-Schema（ビジネスインテリジェンス）を見てください。これは一般的に使用されていて、非正規化されています。 –
プライマリキーは決して変更しない方が良いです。すべての参照を更新する限り、主キーを変更することはできますが、それはちょっと痛みです。
は時々テーブルには天然の非変更の列はありませんと、その場合には、サロゲートが便利です。
しかし、変化のない自然な価値（リサイクルされない従業員IDや変更したくない役割のセットなど）がある場合は、それを使用する方がよいでしょう。
そうしないと、ごくわずかな事態に備えて、何かを満たすための複雑さが生じます。
これは私の意見であり、私の名前はCoddやDateではないので、これを福音としてとらえないでください。
いいえ、いいえ、いいえ、いいえ、いいえ。
キーはデータではありません。キーには意味がありません。このように意味が変わると、キーは変化しません。
キーには、が含まれています。の意味です。エンコードされた意味は、それをデコードするアルゴリズムがない限り、潜在的にはおそらく役に立たないことさえありません。
"admn"から "Aministrator"にルックアップなしでアクセスする方法はないので、実際の意味では "Administrator"はSEKRET ENKODED "useful"キーのすぐ隣にあります。テーブルの横にある実際のデータの代わりにキーを押しますか？
あなたはその後省略形、列挙型のような名前、または何を持っている、をしたい場合はこと、それがデータだ実現、それを呼び出します。それは完全に受け入れられます。 create table(id int not null primary key, abbv char(4), name varchar(64));
しかし、これはキーではなく、整数キーのようにハッシュされません。ヌルターミネータが「edtr」と比較するために4文字の比較と2つの比較を行う整数。次のキーを生成するためのまともな方法はありません：シーケンスの次のもの（ 'admn'、 'edtr'、？）？
あなたは生成能力、簡単な比較、おそらくサイズ（あなたが使用していた可能性がある場合は、あなたのキーとしての僅かな長さ）を失いました。
合成キーを使用します。本当に省略形が必要な場合は、属性列にしてください。
+1感謝、ID /コード/説明はより意味をなさない –
問題ありません。そんなに活発に聞こえて申し訳ありません。 ;） – tpdi
なぜサロゲートキーについてドグマチックなのですか？ mladen-mihajlovicの投稿が指摘しているように、どちらの方法でも引数がありますが、ここでは引数を一方向にまとめただけです。 OPの更新で言及されるように、ビジネスロジックが特定のキー値を切り替えるコードにはよくあるケースがあります。そのような場合、サロゲートキーは、キーが何を理解するのに費やした時間を費やしてミリ秒とバイトを最適化しますか？ –
私は答えがあなたの投稿にあると思います。 user.IsInRole（ "admin"）の例は、主キーchar（4）を持ち、管理者のキーとして "admn"を使用しているので、常にfalseを返します。
私はサロゲートのプライマリキーを変更することはなく、コード内でハードコードされた特定のロールをクエリするための「機能主キー」のオプションを持っています。
+1 ...ハハ！よく目がく –
キーには、特別な意味はありません。条件が変わる傾向があるので、キーが変更を意味する場合はキーを変更する必要があり、変更するキーは実行したくないものです。
また、キーに入れることができる情報の量が非常に限られている場合、そこに持っているのはあまり意味がありません。
自動増分と固定文字キーを比較していますが、このシナリオでは自動増分IDは必要ありません。
異なるルートがあります。 1つは列挙型を使用し、int型にマップします。これらは自動インクリメントされず、テーブルの主キーです。
プライマリキーとして非関連番号を使用する場合は、サロゲートキーと呼ばれ、そのクラスがベストプラクティスだと考えている人は、
http://en.wikipedia.org/wiki/Surrogate_key
あなたは主キーとして「ADMN」を使用する場合、それは自然なキーと開発者の異なるクラスと呼ばれています、それが最善の方法だと信じています。
https://en.wikipedia.org/wiki/Natural_key
人とも同意するつもりはありません。これは古くからの宗教戦争（サロゲート・キー対ナチュラル・キー）です。したがって、あなたが最も快適なものを使用してください。あなたが選択したものに関わらず、意見が一致しないすべての人にあなたの意見を支えるものがたくさんあることをご存じですか。
代理人はアプリのデザインに適しています。それらは、コードから結合されたエントリを緩やかに保ちます。 –
User.IsInRole（UserRoles.Admin）ではなくUser.IsInRole（ "admin"）を参照するコードを記述すると、データベースを再構築する場合にAdminを更新する必要がある場合があります。 –
データベースでプライマリキーは必要ありません。 – paxdiablo