Help us understand the problem. What is going on with this article?

一般的な会員制ウェブサービスでは仮登録とユーザー情報とユーザー認証を別テーブルにした方がいいと思う

More than 3 years have passed since last update.

一般的な会員制ウェブサービスでは
ユーザー仮登録 => メールアドレス認証 => ログイン処理
という手続きを行う。

これを実現するためにユーザーテーブルにはユーザーの登録状態や認証状態などのカラムが追加されることが多い。
しかし、ユーザーテーブルにこれらが集約された設計では、ユーザーの状態を考慮しないクエリを発行してしまうことによるバグが発生しやすい。またクエリの条件が増え複雑になりやすい。
そこで考えたところ、仮登録、ユーザー、ユーザー認証の3つにテーブルを分割することで、その類のバグを減らすことができ、仮登録や認証を実装する際にも様々な恩恵が受けられることに気づいた。

仮登録テーブル(仮登録時にレコードが追加される。)
- メールアドレス
- パスワード
- 認証トークン
- 仮登録日付

ユーザーテーブル(メールの確認処理が終わると追加される)
- ユーザーID
- メールアドレス
- パスワード

ユーザー認証テーブル
- ユーザーID
- 認証トークン
- 認証トークン有効期限

この設計にすると認証時にSELECT * すると余計な情報を取ってきちゃうとか、仮登録の人は除かなきゃとか考えなくて良くなる。
あと仮登録と認証の部分だけやっぱキーバリューストアにしようとかもあとから簡単にできる。

ユーザーの退会とかを考えると結局はユーザーの状態を意識しないといけないが、それでも全部ユーザーテーブルに突っ込むよりはずっといいと思う。

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした