これらのどれが Web アプリケーションで使用するのに適しているのか疑問に思っています。ユーザーがサイトに投稿できる Web アプリがあります。投稿には 3 つの異なるタイプがありますが、1 つのテーブルにまとめることができるほど似ています。それでいいの？
この方法でテーブルを正規化できますか? (どちらかの下にタイプを入れます)
表1
UserPost
post_id
user_id
type
表 2
Post
post_id
datetime
text
または、1 つのテーブルを使用する方がよいでしょうか?
テーブル
Post
user_id
post_id
datetime
type
text
誰かが欠点を指摘できない限り、私は 3 番目の方法に傾いています。
最初のアプローチでは、ユーザーの投稿ごとに両方のテーブルに常に行を作成する必要があります。したがって、テーブルを 1 つだけ持つことによる欠点はありませんuser_id。ユーザー テーブルの外部キーにする必要がありますpost_id。主キーと他の列がデータを保持します。2 つのテーブルを作成する理由はありません。
3 つの異なるタイプの投稿が 1 つの共通フィールドで記述できる場合は、次のような識別子で問題ありませんtype。
表を結合します。表 1 と表 2 のように分割する利点はありません。ここで、表 1 に post_id とは別のキーがある場合、冗長性を排除できます。例：
Table 1
UserPost
user_post_id
user_id
type
Table 2
Post
post_id
user_post_id
datetime
text
あなたの最新のコメントに基づいて、私の理解では、post_id は 3 つのサンプル テーブルすべての候補キーになるということです。それが正しければ、一意の属性セット (投稿の種類ごと) ごとに 1 つのテーブルを作成することをお勧めします。したがって、すべての投稿に共通の属性がある場合は、それらすべてを 1 つのテーブルにまとめるのが理にかなっていますが、タイプが 2 つまたは 3 つある場合は、2 つまたは 3 つのテーブルがより適切です。