私のサイトの 1 つに、各ユーザーの一意のユーザー ID、電子メール アドレス、パスワードなどを含むメインのユーザー テーブルがあります。
電子メールを確認したかどうか、メッセージを投稿したかどうか、アカウントをアップグレードしたかどうか、X を実行したかどうか、 Yなどを行っています。
これらの各フラグは単純な "0" (偽) または "1" (真) であり、これらのフラグに基づいて、私のサイトはユーザーを表示したり、さまざまなことを行ったりします。
私の質問は、これらのバイナリ フラグをメインの Users テーブルに追加すること、またはバイナリ フラグなどのために別のテーブルを作成することのほうが理にかなっていますか?
あなたがどこから来たのかを理解できるように、あなたの理由 (およびあなたのアプローチの利点) を説明してください。
これらのフラグはすべて保存する必要がありますか、それとも計算できますか? たとえば、ユーザーがメッセージを投稿していない場合、これは MESSAGE テーブルをクエリすることで簡単に判断できます。
「計算可能な」フラグを物理的に保存することは冗長であり、データの不一致の可能性を開きます。たとえば、ユーザーがメッセージを追加しても、アプリケーションのバグによってフラグの更新が妨げられた場合はどうなるでしょうか? このような「非正規化」は、パフォーマンス上の理由から正当化される場合がありますが、現実的な量のデータと代表的なワークロードでパフォーマンスを測定した後にのみ、この決定を下してください。
OTOH、一部のフラグは「本物」の場合があります（たとえば、ユーザーが電子メールを確認したかどうか）。そのようなフラグが比較的静的な場合 (つまり、データ モデルを設計する時点で事前にわかっている場合)、単純なブール (または同等の) フィールドとして USER テーブル自体に直接格納します。
実行時にかなりの柔軟性が必要な場合にのみ、USER テーブルと N:1 の関係にある別の FLAG テーブルを使用することを検討してください。これはEAVの一種です。
それらをまとめておくことには利点があり、それらを分離することには利点があります。Usersテーブルにフラグを配置すると、結合を使用してそれらを取得する代わりに、ユーザー ID に対する単純なクエリを使用して、そのユーザーに関するすべての情報を取得できます。
一方、それらを別のテーブルに置くと、Usersテーブルにあるデータから「論理的に」分離され、完全に無関係になる可能性があります（両方がユーザーについて話している場合でも）。したがって、より明確なデータベース構造が得られます。
考慮すべきもう 1 つのことは、そのようなデータを変更して取得する必要がある頻度です。たとえば、ログイン時にそれらが必要な場合は、それらを同じテーブルに保持して、一度にすべてのログイン データを取得することをお勧めします。代わりに、それらを繰り返し変更する必要がある場合は、選択を別のテーブルに置く必要があります。
とは言っても、私はいずれにせよ 2 つのテーブル ソリューションを使用しますが、DB スキーマでそれらを表示するのが好きな方法です。