ここでは、初心者から実践的に学べるプログラミングスクール「ウェブカツ!!」のWEBサービス部を受講している生徒の方向けにさらに「データベースのテーブル設計」についての理解度を上げるため特訓をしていきます。
ここでは「MySQL」を題材にします。
DBのテーブル設計鬼練８：ユーザーテーブルを作ろう
問題
「情報の洗い出し方」は分かってきたと思うので、ユーザーテーブルを作りましょう。
下記の問題に答えてください。
下記の情報を保持しておくためのユーザー情報のテーブル定義書を作成してください。
- ニックネーム
- 氏名
- メールアドレス
- パスワード
全て必須項目とします。
テーブル名は「users」としてください。
ヒント
分かりますよね。SQL鬼練の方でもやってるしね。
テーブル定義書はSQL鬼練で出てくるフォーマットのもので作りましょう。
答え
答えは
ですね。
テーブルには基本的に各レコードに「ID」を振っておいた方が、内部で使い回しやすいですね。
今回はユーザーテーブルのなので、ユーザーIDという意味の「id」というカラム名を作りました。
この「ユーザーID」という名前の事を「論理名」と言います。
また、「id」というカラムに実際につける名前のことを「物理名」と言います。
- 論理名は「開発者なり人がパッと分かる名前」
- 物理名は「実際にDBについている名前」
ですね。
データ型は制約についてはWEBサービス部やSQL鬼練でもやってるので割愛します。
必須項目なんで今回は全部「NOT NULL」にしてますが、任意項目ならカラムは「空」になる可能性があるので「NULL」を許容するようにするか、DBへ送信する前にアプリ側（サービス側と言ったりもします。「phpの処理で」ってこと）で、適当な値を必ず詰めるようにする。といった対応になりますね。
他にもテーブルにはお決まりでつけるものがありましたね。
- 登録日時（レコードが登録された日時）
- 更新日時（レコード更新された最新の日時）
- 削除済み（レコードを論理削除したい場合につけとく。大抵はレコードは物理削除せずに論理削除するのでつける。）
です。
この３つのカラムはなくてももちろん動かせますが、あった方が便利ですよね。
もし「ブログの記事」テーブルなんてものだった場合は、
「最新の記事順で画面に表示させたい」
なんてこともあります。
ユーザーテーブルなら
「◯年◯月◯日〜◯年◯月◯日までに登録したユーザーの情報を元に〜」
みたいな条件でデータベースを検索することもしばしばあります。
（マーケティング部署からマーケティングの集計に使うためにそういう依頼があったりもします）
また、「不具合」が起こった時に影響範囲を調べる時にも使われます。
「◯年◯月◯日◯時◯分◯秒〜◯年◯月◯日◯時◯分◯秒」までの間にユーザー情報を更新する機能に不具合が起こっていたのなら、
不具合の影響対象となるユーザーはその日時間に更新をしたユーザーだってことになりますね。
（次には、その絞り込んだ人たちの中から実際に不具合が起こったのかを調べていく。といった影響調査の手順になっていきます）
更新日時はデフォルト値を「CURRENT_TIMESTAMP」をつけないと自動的に最新日付にならないので注意が必要でしたね。
また、今回「氏名」に関しては１カラムにまとめてますが、「姓」「名」と２カラムにする場合もあります。
まぁ、テーブル１つなんで簡単でしたね。
