これが初心者に聞こえる場合は申し訳ありませんが、これは継承されたクラスのデータベース設計に関連するものです。
現在、システムに登録するためのユーザーには、メンバーとスタッフの 2 種類があります。どちらも同じプロパティ (名前、生年月日、連絡先番号) を共有し、独自の使用法 (メンバーの場合はメンバーシップ番号、スタッフの場合はスタッフの役職) を所有しています。現在、それらは両方ともデータベースに 2 つの異なるテーブルとして格納されており、相互に関係はありません。
私は今、システム内の Person クラスを拡張するクラス呼び出し Member と別の Staff を持ちながら、すべての共通プロパティを持つ Person というエンティティを作成することを考えています。しかし、データベースの設計に問題があります。人のタイプを示す type プロパティを持つ Person というテーブルが必要ですか、それとも、それらを分離する 2 つのテーブルがある既存のデザインに固執する必要がありますか?
場合によります。
ポリモーフィック クエリを実行しない場合は、現在の設計に固執します。
この種の設計は、文献では「具象クラスごとのテーブル」と呼ばれています。
一方、ほとんどのクエリが「メンバーかスタッフかに関係なく、システム内のすべての人を教えてください」のようなものになる場合は、それらをすべて Person という 1 つのテーブルにまとめることができます。
この種の設計は「クラス階層ごとのテーブル」と呼ばれます
明らかに、これにより、継承されたクラスのプロパティに対応するすべての列がデータベースで null 可能でなければならないことが義務付けられます。
それが受け入れられない場合 (そうなるとは信じがたいですが...)、完全を期すために、「クラスごとのテーブル」と呼ばれる 3 つのクラス、3 つのテーブルの構造になる可能性があります。
これには厳格なルールはありません。私は通常、クラス階層ごとのテーブルが最も理にかなっているシステムで作業する傾向がありますが、それが当てはまる場合とそうでない場合があります。