ユーザーテーブルの設計に必要な情報をまとめました。
必要な情報
利用するアプリによって、色々分かれるとは思いますが、必要そうと思われる情報を書き出してみます。
| 項目 | データ型 | 説明 |
|---|---|---|
| ユーザーID | 数値型(INT) | ログインIDとひとまとめにしてしまう場合もあります。 |
| ユーザー名 | ||
| ログインID | 固定長(VARCHAR) | ユニーク制約をかける。 |
| パスワード | VARCHAR | 平文ではなく、暗号化関数等でハッシュ化した値を入れます。 |
| 作成日 | DATE | レコード挿入日を入れる。 |
| 更新日 | DATE | レコード更新日を入れる。 |
| 削除日 | DATE | ここに日付が入っているレコードは論理削除されたとみなす。 |
ユーザーIDとログインIDは別にするのか？
色々ありますが、分けるメリットデメリットは下記です。
メリット
ユーザー情報と、ログイン情報を別々にできるので、ユーザー情報だけ保管したりできる。
例えば、ユーザーがそのシステムを退会した場合でも、ユーザー情報だけ論理削除して、ログイン情報は物理削除する等ができたりします。
デメリット
DB設計がわかりずらくなります。特に小規模なシステム等では、ユーザーとログイン情報はまとめてしまうということが多いかもしれませんね。（むしろ、わかりやすさを重視してこれが大半のようです。）
では、どう設計するか？
ユーザーIDとログインIDを分けない場合
USER(ユーザーテーブル)
| 項目 | 説明 |
|---|---|
| ユーザーID（兼ログインID) | 主キーにする。 |
| ユーザー名 | |
| パスワード | |
| 作成日 | レコード挿入日を入れる。 |
| 更新日 | レコード更新日を入れる。 |
| 削除日 |
非常にシンプルですね。
ユーザーIDとログインIDを分ける場合
1.ユーザー情報もログイン情報も一つのテーブルにしてしまう。
USER(ユーザーテーブル)
| 項目 | 説明 |
|---|---|
| ユーザーID | 主キーにする。 |
| ユーザー名 | |
| ログインID | ユニーク制約をかける。 |
| パスワード | |
| 作成日 | レコード挿入日を入れる。 |
| 更新日 | レコード更新日を入れる。 |
| 削除日 |
一つにまとまっているので、非常にわかりやすいですね。
ただ、これだと、ユーザーレコードを物理削除しないのであれば、いなくなったユーザーのログインIDが使えなくなってしまいます。
2.ユーザー情報と認証情報を別々にテーブルにして、それぞれ主キーを設定する。
USER(ユーザーテーブル)
| 項目 | 説明 |
|---|---|
| ユーザーID | 主キーにする。 |
| ユーザー名 | |
| 作成日 | レコード挿入日を入れる。 |
| 更新日 | レコード更新日を入れる。 |
| 削除日 |
AUTHORIZATION(認証テーブル)
| 項目 | 説明 |
|---|---|
| ユーザーID | ユーザーIDの外部キーにする。 |
| ログインID | 主キーにする。 |
| パスワード | |
| 作成日 | レコード挿入日を入れる。 |
| 更新日 | レコード更新日を入れる。 |
これなら、論理削除されたユーザーIDがいた場合は、AUTHORIZATIONテーブルだけ物理削除すれば、ログインIDが欠番になることはなくなりますね。
この記事へのコメントはありません。