Ruby on Rails プロジェクトに取り組んでいます。プロジェクトには、「Post」と呼ばれるメイン データベース テーブルがあります。
このテーブルは、質問、回答、コメント、お知らせをさまざまな投稿タイプとして保存するために使用されます。現在、データへのアクセスには 1 つのモデルのみを使用しています。しかし、システムに取り組んでいる間は、散らかっているように感じます。すべての投稿タイプにはいくつかの違いがあるためです。
ベスト プラクティスとは:
簡単な答え: 場合によります。
あなたが今行っていることは、Single Table Inheritance (STI) にかなり近いものですがPost、さまざまな動作をすべて含む単一のクラスを使用しているように思えます。STI は、モデル データを格納するための有効なアプローチですが、他のすべての方法と同様に、利点と欠点があります。
私のお勧めは、個別のクラスを使用して、個別のドメイン モデルの動作をカプセル化することです。これは OOP の基本的なパラダイムであるため、おそらくベスト プラクティスであると言えます。
クラス間で動作を分割すると仮定すると、単一のテーブルを使用してそれらを格納するか、複数のテーブルを使用するかという問題は、クエリの複雑さと、モデル全体に共通のフィールドがいくつあるかによって異なります。彼らが多くの共通分野を共有している場合、STI はうまく機能する可能性があります。そうでない場合は、余分な読み取り/書き込みのオーバーヘッドを享受することはおそらくないでしょう。しかし、それはすべて二次的なものであり、アプリが成長し、使用パターンについてさらに学ぶにつれて明らかになる可能性があります。
STI を使って試してみて、どうなるか見てみましょう。物事を複数のテーブルに分割することは、その逆よりも簡単であるため、移行パスは必ずしも難しすぎるわけではありません。
選択は特定の状況ごとに基づいている必要があると思います。各オプションの長所と短所を列挙するだけです。調査して決定するポイントは、エンティティの種類ごとの違いの数、エンティティへのアクセス方法、エンティティの種類ごとの使用頻度、コードの保守性、将来の変更の予測などです。