アソシエーション

1:多

  • 芸能人と一般人のパターン
  • 多が1を知る必要がある

多:多

  • タグ付けのテーブルなどで使われるパターン
  • 2次元では表現できないので、中間テーブルを用意する

1:1

  • 目的ごとに1つのテーブルを分けるパタン
  • 意味論的と変更可能性を考慮して設計する

例) 例えば、UserテーブルとそのUserのCredentialが合った場合、

  • UserがCredentialのIDを所有する
    • 意味論的にusers knows credential_idの方がcredentials knows user_idより良いから
  • ただし、今後の変更で1:多になるなら
    • つまり、User:Credential = 1:多になる場合はCredentailがUserを知る必要がある
    • スカラ値は正規化ではRDBでは許容されないから
  • データ的にprimary度が高い方を親とする
  • 作られる時系列を考慮する
    • Nullが埋まるFKはよくないので、先に作られる方を親とする
    • もし、credentials knows user_idにすると、credentailを作る時に、user_idが必要になる