user_idカラムは何の為にありますか？

laravelを勉強中です。
教材でツイッターもどきのアプリを作成中です。
ユーザーテーブルが作り終わり、ツイートテーブル(microposts_table)を作成中なのですが、
下記の場合、user_idカラムの存在意義は何ですか？
また、外部キー制約についても、まだあまり分かっていません。

public function up()
    {
        Schema::create('microposts', function (Blueprint $table) {
            $table->increments('id');
            $table->integer('user_id')->unsigned()->index();
            $table->string('content');
            $table->timestamps();

            // 外部キー制約
            $table->foreign('user_id')->references('id')->on('users');
        });
    }

    public function down()
    {
        Schema::dropIfExists('microposts');
    }

退会済みユーザー

2018/08/13 18:11

「教材でツイッターもどきのアプリを作成中」その教材に書いてあることなのでは？「教材」がなんなのかもわからない回答者が、この質問を読んで回答できるとは思えません。

行動規範の内容に同意します

回答2件

この質問内容だけでは要件を全て把握しきれないので
あくまで想像による部分が大きいのですけど。
（つまりあまり良くない質問です。自分だけが知っている情報をなくすように努めてください）

その情報が誰のものであるかを特定するために置かれるものと思います。
外部キー制約はそのカラムにある情報と紐づかれたテーブルのカラムの情報が一致する必要がある、という制約になります。
つまり、「誰のものであるか特定するために置かれる」もののはずが、実際にそのuser_idにあたる情報がテーブルに存在しなかった場合、
userの情報が取得できませんよね？

usersテーブルがどんな情報を保管しているかによりますが、「名前」に関するカラムがあった場合は、名前が取得できなかったり。

「じゃあこのツイートテーブルにユーザー情報全部持てばいい」と思うかもしれませんが、そういうわけにはいきません。

なぜか。
あくまで「ツイートテーブル」はツイートに関する情報のみを保管する目的があるものだからです。
全てのツイートに対してユーザー情報すべて持った場合、どうなるかわかりますか？
同じ情報が全てのツイートに持たれることになりますよね。
ではユーザー情報を変更したいときにどうなるか。
すべてのツイートテーブルを更新しなければなりませんよね。
退会した場合はどうするか。

「ツイートテーブル」なのにユーザーの情報まで持つことは、データ上、無駄な情報が増えるだけではなく、様々な面で手順が増え、非効率となるわけです。

手順が増えることはその分、バグが発生しやすくなります。

ただ、外部キー制約をした場合、今回で言うと「ツイートテーブル」のデータは削除できますが、「ツイートテーブル」にあるusersのidが1つでもあった場合、そのusersのデータは削除できません。
紐づけができなくなるためです。
そのユーザが退会した場合にどうするかというのは要件次第にはなりますが、
一般的には「先に該当ユーザーの紐づく別テーブルの情報を全て削除してからusersテーブルの情報を削除する（物理削除）」か、「usersテーブルにステータス情報を持っておき、”退会”に切り替える（論理削除）」のいずれかになると思います。
後者の場合は、これも要件次第ですが、退会ユーザーのツイート情報を表示するかどうか、ですね。
「表示はするが”退会ユーザ”と表示する」（teratailみたいなやり方）ケースと「そもそも表示しない」ケースがあります。
いずれにしても、ツイートテーブルのuser_idからusersテーブルをJOINした上でステータスを確認する必要があります。

以上、こんな感じです。
ほぼ想像なので、自身が把握されている要件や考えたこと調べたことと差異がありましたら教えてください。

投稿2018/08/13 21:01