ステータスを持つユーザーがいて、ユーザーのステータスが「アクティブ」、「一時停止」、または「非アクティブ」であるとしましょう。
さて、データベースを作成するとき、私は疑問に思っていました...文字列値を持つ列（列挙型またはルールが適用されたもの）を持っている方が良いので、クエリを実行して現在のユーザーステータスを知るか、結合する方が簡単です可能性のあるユーザーステータスを含む UserStatuses テーブルに参加する必要がありますか?
もちろん、アプリケーションのユーザーがステータスを作成することはできません。
編集：いくつかの明確化
全体として、誰もがあなたの質問への回答の重要な要素を見つけたと思います。ただし、それぞれに優れた点があり、個別にではなく、まとめて使用する必要があります。
logixologist が述べたように、通常、適切な量のノーマライゼーションはパフォーマンスを向上させると考えられています。しかし、logixologist とは対照的に、あなたの状況は正常化に最適な時期だと思います。あなたの問題は、正規化の問題のようです。この場合、Santhosh が提案したように数値キーを使用すると、ステータスのデコードを含むコード テーブルに戻り、レコードごとに保存されるデータが少なくなります。この違いは、小規模な Access データベースでは見られませんが、数百万のレコードがあり、それぞれにステータスがあるテーブルでは見られる可能性があります。
David Aldridge が示唆したように、この特定のデータ ポイントを正規化すると、より制御されたエンド ユーザー エクスペリエンスが得られることに気付くかもしれません。ステータス フィールドを正規化すると、後でステータス フラグを 1 つの場所で編集し、その変更をデータベース全体に永続化させることもできます。あなたの上司が私のような場合は、非アクティブのステータスをクローズに変更する必要があるかもしれません (そして、来週また戻します!)。これは、ステータス フィールドが正規化されていない場合、より多くの作業になります。正規化することで、参照整合性を強化することも容易になります。ステータス キーがステータス コード テーブルにない場合は、メイン テーブルに追加できません。
将来クエリを実行する際のパフォーマンスが気になる場合は、考慮すべき点がいくつかあります。ステータスを戻すには、正規化されている場合、クエリに結合を追加します。その結合は、おそらくどのサイズのレコードセットでも害を及ぼすことはありませんが、処理する必要がある生のテキストの量を制限することで、より大きなレコードセットに役立つと思います. データをクエリするときのパフォーマンスが主な関心事である場合は、クエリを最適化する方法に関する優れたリソースを次に示します: http://www.sql-server-performance.com/2007/t-sql-where/ここで説明するルールの多くは、結合自体に適用する包含基準にも適用されます。
お役に立てれば！
クリストファー
0、1、2 などの整数値を使用することをお勧めします。これが修正された場合。レポートで結果を解釈するときに、これらのステータスを文字列に戻すことができます。