本記事について
今後のデータベース設計時の参考になればと思い、テーブル設計について、講義内容や職場での体験をまとめたもの。
テーブル設計する上で大切なこと
データが取り出しやすいか？
更新がしやすいか？
将来変更を強いられた場合、柔軟な対応が可能か？
1つのテーブルにコードと名称が入っている
名称とコードを分けた方が良い。
都道府県、市区郡町村、住所1、住所2、建物名というように、住所を過剰に分割している。
| ID | 都道府県コード | 都道府県名 | 市区郡町村コード | 市区郡町村名 | 住所1 | 住所2 | 建物名 |
|---|---|---|---|---|---|---|---|
| 1 | 13 | 東京都 | 103 | 港区 | 西麻布1丁目 | 1番1号 | XXビル |
同じ意味、同じ値のカラム
作成日時と登録日時は同じ値が入る。どちらか1つで良い。
| ID | 作成日時 | 登録日時 | 更新日時 |
|---|---|---|---|
| 2 | 2021-07-05 01:58:04 | 2021-07-05 01:58:04 | 2021-07-06 02:30:01 |
一つに統一できるカラムが存在する
削除日時に日付が入っていれば、いつ削除したかどうか判別できる。つまり、削除区分は不要。
| ID | 削除日時 | 削除区分 |
|---|---|---|
| 2 | 2021-07-01 03:20:10 | 削除済 |
カラム名、値が無駄に分かれている
登録年月日1つあれば、登録年、月、日は取得できる。なぜ分けたのか謎。
| ID | 登録年 | 登録月 | 登録日 | 登録年月日 |
|---|---|---|---|---|
| 10 | 2021 | 07 | 01 | 2021-07-01 03:20:10 |
同じ意味かつ、今後追加される可能性のあるカラムが複数存在
コメントが横持ちになっている。
コメントが増える都度、テーブル変更が発生する上、sqlも複雑になる。
| ID | 名前 | 予定１ | 予定２ | 予定３ | 予定４ |
|---|---|---|---|---|---|
| 20 | 田中一郎 | 今日は宿題をする | 明日は買い物に行く | 明後日は学校に行く | 明明後日はデートする |
備考になんでも詰め込む
備考やその他のように、入力ルールが不明確なカラム。
後で分けようと思ってもデータを取り出すことができない。
電話番号を自宅番号と携帯番号に分ければ良い。
都合の良い時間は、配達希望時間などのカラム名が望ましい。
| ID | 名前 | 郵便番号 | 住所 | 電話番号 | 備考 |
|---|---|---|---|---|---|
| 33 | 鈴木二郎 | 1231234 | 東京都葛飾区柴又 | 09012345678 | 携帯番号は080XXXXXXXX、配達に都合の良い時間は午前中 |
以上。