チェックリスト

一つのカラムにカンマ区切りで値を入れていない？

あるテーブルに comment_ids みたいなカラムがあることを想定します。
そして1,2,3 のように string でカンマ区切りの値が入る場合が今回のケースになります。

中間(交差)テーブルを使いましょう。

階層構造が1つや2つの場合は、非常にシンプルでSQLも面倒にはなりません。

具体的には、下記の通りです。

id という名前にしているテーブルをよく見ますが、この id に明確な意味はありません。
account_id や user_id などのように明確にしましょう。

下記記事のコメントでも書かれている通り、なんでもかんでも外部キーを貼ることこそがアンチパターンなのでしょう。
デメリットのところが非常にわかりやすかったので、そのまま引用させていただきます

外部キーを貼るデメリット

シャーディングや別DBで利用できない
ON UPDATE CASCADE 制約を詳しく無い人がさわって想定外のレコードが変更される可能性がある
上記、SELECT 文走らせまくるとか、ER図が無いと辛い
そもそも DELETE が推奨されておらず論理削除がメインなので問題がおきづらい
テストデータの作成にコストがかかる
フレームワークで外部機キー制約っぽいものを制約しているものがある
行を挿入する前に、親の行の存在確認をしないといけない。=> コード量が増える
制約があっても確認するはず
insert の失敗時に制約エラーの内容からハンドリングするほうがコード量増えそう
第四章キーレスエントリ（外部キー嫌い） - Qiita コメント箇所より引用

CASCADEを指定すると，被参照表の主キーに変更があった場合，外部キーも同じように変更されます。
参照制約の定義

ON DELETE SET NULL・・・参照先deleteすると参照元がnullにする
ON UPDATE CASCADE・・・

下記記事でも検証してくれていますが、ON UPDATE CASCADE を指定すると、参照先をupdateした際、参照元も同じupdateがされます。
MySQLの外部キー制約RESTRICT,CASCADE,SET NULL,NO ACTIONの違いは？ - Qiita

第6章のポリモーフィック関連の箇所です。

SQL を実行するときに、id だけを取得するだけでなく、type の値も同時に確認する必要が出てきます。
なので、typeが2つ、3つ存在するのであれば、そのうち1つしか外部結合ができなくなってしまいます。

年ごとに Bugs_2018 Bugs_2019 Bugs_2020 と増やしていく設計を考えている場合は、水平パーティショニング、垂直パーティショニングを検討しましょう！！
データパーティショニングで巨大DBも楽々管理