これはなに

データベースの論理設計をする際に気がついたことのメモです。

サービス横断型のユーザIDテーブル

概要

• 概要

  • リクルートIDみたいなやつの設計
• 前提

  • サービスによって持つ情報は異なるので、ユーザー基本情報TBLと各サービス用ユーザー情報TBLがわかれている
  • サービス横断型のユーザーIDがどこに紐づくのか？　というのが問題
• 備考

取れる手段

• 選択肢

  • ユーザー基本情報TBLに紐付ける
  • サービス用ユーザー情報TBLに紐付ける

採用したもの

• 採用

  • 基本情報TBLに紐付ける
• 理由

  • ユーザーが複数のサービスIDを持つことを許すか？　というのが論点

    • 基本的には一意性を持たせたいが、結局のところ複数のIDはできてしまう。人間が複数のアドレスで登録してきて、同一ではないですと主張されたら対応できない？
  • なのでサービスごとにIDが変わることは許容しつつ、紐付けるユーザー基本情報でユーザーの一意性を担保する

    • サービス用ユーザー情報がどの人間にひもづくか？　は同一性判断のロジックが担当する

経過、雑記

• 本当にこれで良いのか？　はちょっと疑問

  • IDを分けられるようにしても、同一性チェックのところで結局はユーザー自身に同一人物ですか？　と聞く必要は出てくる

    • 他人と統合するわけにはいかないし。情報流出したら困るから
  • そこでごねられたらやはり別人として処理せざるを得ないし、完全に人間の一意性をDB上で担保するのはきついかも
  • だったらわかりやすさとして、基本情報に紐づけてしまってもよいのでは？