username私には 4 種類のユーザーがいて、それぞれに特定のデータがありますが、password..などの共通データも共有しています。
私の最初の考えは、列を持つメインusersテーブルを作成することです。user_type次に、ユーザーデータをクエリするときに、最初にそれらを選択しuser_type、次に実行に応じてoutput別のクエリを実行して、「ユーザータイプ」固有のデータを取得できます。1 つのクエリで、理想的には外部キーを使用して、すべてのユーザー関連データを取得できればよいので、私はこれが好きではありません。
2 番目のアイデアはuser_type、テーブルに列を持たずusers、代わりに特定のユーザー タイプ テーブルからメイン テーブルの行を指す外部キーを使用することusersです。私はそれが少し好きですが、ユーザーデータを取得する必要があるたびに N クエリを実行する必要があると思います.N はユーザータイプの数です.
他にオプションはありますか？そのような場合の良い習慣は何ですか？
どうもありがとう
あなたのケースは、クラス/サブクラスのインスタンスのように見えます。
サブクラスを処理する SQL テーブルを設計するには、2 つの古典的な方法があります。それぞれに長所と短所があります。
1 つの方法は、「単一テーブル継承」と呼ばれます。この設計では、すべてのタイプのユーザーに対して 1 つのテーブルしかありません。特定の列が特定の行に関連しない場合、交差は NULL のままになります。ユーザー タイプを示す列を追加できます。
もう 1 つの方法は、「クラス テーブルの継承」と呼ばれます。これは、Nanego の回答によく似ていますが、いくつかのマイナーな変更が加えられています。ユーザー用に 1 つのテーブルがあり、すべての共通データと id フィールドがあります。サブクラスごとに 1 つのテーブルがあり、そのサブクラスに関連するデータが含まれています。多くの場合、id フィールドは、users テーブル内の一致する行の id フィールドのコピーとして設定されます。このように、サブクラス キーは 2 つの役割を果たし、主キーとユーザー テーブルを参照する外部キーの両方として機能します。この最後の手法は「共有主キー」と呼ばれます。挿入時に少しプログラミングが必要ですが、それだけの価値があります。これにより、関係の 1 対 1 の性質が強化され、必要な結合が高速化されます。
SO のタグとして、または Web 上の記事として、これら 3 つのデザインすべてを検索できます。
ディスク容量をより効率的に使用できますが、別々のテーブルに分割することの問題は、条件付き結合 (user_type に基づくユーザー タイプ固有のテーブルへの結合) が事実上必要になることです。これを SQL としてコーディングするのは面倒なことです。最近では、ディスク容量を気にする人がいるでしょうか?
より適切なオプションは、ユーザー タイプによっては使用されない列があることを認識して、任意のユーザー タイプに関する情報を格納するのに十分な列を持つ 1 つのユーザー テーブルを用意することです。未使用の列を持つことの「非効率性」は、実行速度とクエリの単純さで補われます。
別のユーザー タイプを取得した場合に備えて、簡単に拡張することもできます。テーブルを追加するよりも列を追加する方がはるかに簡単です。また、ユーザー タイプを追加すると、新しい列の必要性が減少します (異なるユーザー タイプはそれほど多くありません)。保存する必要があるユーザーに関するもの)
それを行う私の方法は、共通フィールドを持つ 1 つのテーブル "Person" と、外部キー "person_id" を持つユーザーのタイプごとに 1 つのテーブルを作成することでした。
リクエストでは、1 つのタイプのユーザーのすべてのデータを取得するために、foreign_key を使用して 2 つのテーブルを結合する必要があります。
何種類のユーザーがいますか?