アキバのバイト女王 - MySQL編
第一幕: 店長の突然のクイズ
暇な午後、店長が突然私にニヤリと笑いかけた。浩三さんも隣で困った顔をしている。

店長
おい、君。データベースって知ってるか?

私
え?データベース?あの…コンピューターの…?

店長
そうだ!じゃあ、MySQLでテーブルを作る問題を出してやろう。テーブル名がtest、フィールドが数字のid、20文字のnameのテーブルを作成してみろ!

私
え?!え?!わからないです!

浩三
あの、店長さん…

店長
答えはこうだ!
Input
CREATE TABLE test (id INTEGER, name CHAR(20));
Output
テーブル 'test' が正常に作成されました。
- id: INTEGER型のフィールド
- name: CHAR(20)型のフィールド
Explanation
テーブルを作成する基本的なSQL文。
CREATE TABLE
でテーブル作成を宣言test
がテーブル名id INTEGER
で整数型のidフィールドを定義name CHAR(20)
で20文字固定長のnameフィールドを定義

浩三
でも店長さん、実際の現場ではCHARよりもVARCHARを使うことが多いですし、PRIMARY KEYやAUTO_INCREMENTも…

店長
細かいことはいいんだよ!基本を覚えるのが先だ!

私
あの…全然わからないです…
第二幕: 次々と出される問題

店長
じゃあ次だ!テーブル名がlog、フィールドが日付のLD、時間のLT、100文字のlogのテーブルを作成しろ!

私
え…えーと…
Input
CREATE TABLE log (LD DATE, LT TIME, log CHAR(100));
Output
テーブル 'log' が正常に作成されました。
- LD: DATE型のフィールド(日付)
- LT: TIME型のフィールド(時間)
- log: CHAR(100)型のフィールド(100文字)
Explanation
異なるデータ型を使用したテーブル作成。
DATE
型で日付を格納TIME
型で時間を格納CHAR(100)
で100文字固定長のログメッセージを格納

浩三
あの、店長さん…実運用では、ログテーブルにはTIMESTAMPを使って、インデックスも設定しないと…

店長
浩三、細かい話は後でいい!今は基本だ!

私
DATE型とTIME型って違うんですね…
第三幕: テーブル変更の連続攻撃

店長
よし!今度はテーブルを変更してみよう!testテーブルに日付のudでフィールドを追加する、場所はnameの後ろとする!

私
変更?!追加?!
Input
ALTER TABLE test ADD ud DATE AFTER name;
Output
テーブル 'test' が正常に変更されました。
新しい構造:
- id: INTEGER
- name: CHAR(20)
- ud: DATE (nameの後に追加)
Explanation
既存のテーブルにカラムを追加する操作。
ALTER TABLE
でテーブル変更を宣言ADD
で新しいカラムを追加AFTER name
で挿入位置を指定

浩三
店長さん、本番環境でALTER TABLEを実行するときは、必ずバックアップを取って、メンテナンス時間を確保して…

店長
浩三、うるさいな!

店長
次!testテーブルのidのデータ型を8文字に変更する!
Input
ALTER TABLE test MODIFY id CHAR(8);
Output
テーブル 'test' が正常に変更されました。
- id: CHAR(8) に変更 (INTEGER → CHAR(8))
Explanation
既存カラムのデータ型を変更する操作。
MODIFY
で既存カラムの型を変更INTEGER
からCHAR(8)
に変更- データの互換性に注意が必要

浩三
ちょっと待ってください!INTEGERからCHARに変更するなんて、既存のデータが…

店長
浩三、黙ってろ!

私
えーと、データが変わっちゃうんですか?
第四幕: さらなる変更とプロの警告

店長
次だ!usrテーブルのunameのフィールド名をusernameに変更する、データ型は15文字とする!
Input
ALTER TABLE usr CHANGE uname username CHAR(15);
Output
テーブル 'usr' が正常に変更されました。
- uname → username に変更
- データ型: CHAR(15)
Explanation
カラム名とデータ型を同時に変更する操作。
CHANGE
で既存カラムの名前と型を変更uname
からusername
に名前変更- 同時にデータ型も指定

浩三
店長さん!カラム名を変更するとアプリケーションのコードが全部エラーになります!

店長
そんなの開発者の問題だ!

店長
次!usrテーブルのfamilyのフィールドを削除する!
Input
ALTER TABLE usr DROP family;
Output
テーブル 'usr' が正常に変更されました。
- family カラムが削除されました
- データも完全に削除されました
Explanation
カラムを完全に削除する操作。
DROP
でカラムを削除- カラムに含まれていたデータも全て削除される
- 復元は不可能

浩三
待ってください!DROPは取り返しがつかないです!バックアップなしでやったら…

店長
浩三、もう黙ってろ!

私
あの…データが消えちゃうんですか?
第五幕: 恐怖のDROP TABLE

店長
今度は究極の問題だ!crashテーブルを削除する!

私
削除?!
Input
DROP TABLE crash;
Output
テーブル 'crash' が完全に削除されました。
- テーブル構造とデータが全て削除
- 復元は不可能
Explanation
テーブル全体を削除する操作。
DROP TABLE
でテーブルを完全に削除- 構造もデータも全て削除される
- 最も危険なSQL操作の一つ

浩三
店長さん!DROP TABLEは絶対に本番環境では使ってはいけません!

店長
crashテーブルだから大丈夫だ!名前からして不要だろう!

浩三
そういう問題じゃないです!権限管理で普通はDROPできないようにしてるんです!

私
あの…私にはよくわからないですが、浩三さんが心配そうです…
第六幕: データを見るクエリ

店長
じゃあ今度は見るだけだ!scheduleテーブルからpdate・uid・memoを表示する!

私
見るだけなら安全ですね…
Input
SELECT pdate, uid, memo FROM schedule;
Output
+------------+--------+------------------+
| pdate | uid | memo |
+------------+--------+------------------+
| 2025-07-08 | alice | Meeting with... |
| 2025-07-09 | bob | Project review |
| 2025-07-10 | carol | Database backup |
+------------+--------+------------------+
Explanation
テーブルから特定のカラムを取得する操作。
SELECT
で取得するカラムを指定FROM
でテーブルを指定- カンマ区切りで複数カラムを指定

浩三
これは安全ですね。SELECTは読み取り専用なので。

店長
そうだ!じゃあ条件付きの検索だ!usrテーブルから、familyが2のuid・unameを表示する!
Input
SELECT uid, uname FROM usr WHERE family = 2;
Output
+--------+----------+
| uid | uname |
+--------+----------+
| tanaka | 田中 |
| suzuki | 鈴木 |
+--------+----------+
Explanation
条件を指定してデータを絞り込む操作。
WHERE
で条件を指定family = 2
で family カラムが2のレコードのみ抽出- 指定したカラムのみ表示

私
WHEREで条件を決めるんですね!

浩三
SELECTは安全ですが、大量のデータがあるテーブルでは、LIMITを使った方が…

店長
また始まった…
第七幕: データ追加で締めくくり

店長
最後だ!usrテーブルにuidが「agatha」、unameが「christie」となるデータを追加する!
Input
INSERT INTO usr(uid, uname) VALUES("agatha", "christie");
Output
1 row affected.
usrテーブルに新しいレコードが追加されました:
- uid: agatha
- uname: christie
Explanation
テーブルに新しいデータを追加する操作。
INSERT INTO
で挿入するテーブルを指定(uid, uname)
で挿入するカラムを指定VALUES
で実際の値を指定

浩三
店長さん、INSERTする前に、重複チェックやバリデーションを…

店長
浩三、もういい加減にしろ!

私
あの…結局、浩三さんの言ってることは正しいんですか?

店長
あー…まあ…基本を覚えるのが先だから…

浩三
私の言ってることは、実際の現場での経験ですから…勉強としては店長さんの教え方で十分ですよ。

私
なるほど…勉強用と実際の現場では違うんですね…
エピローグ: 学んだこと

私
MySQLって…すごく複雑なんですね…

店長
まあ、基本だけ覚えてれば十分だ。

浩三
基本は確かに大切ですが、実際に使うときは、権限管理、バックアップ、パフォーマンス、セキュリティ…色々考慮することがあるんです。

私
でも、今日教えてもらった基本があれば、その先も学べそうです!

店長
そうだ!基本が一番重要だからな!

浩三
そうですね。基本を理解してから、実践的な部分を学んでいけばいいと思います。
こうして、私の初めてのMySQL体験は終わった。店長の基本的な教えと、浩三さんの実践的な警告。両方とも大切なことを学んだ気がする。
MySQL コマンドリファレンス
今回学んだコマンド
テーブル作成
CREATE TABLE
- 新しいテーブルを作成- データ型:
INTEGER
,CHAR(n)
,DATE
,TIME
テーブル変更
ALTER TABLE ... ADD
- カラム追加ALTER TABLE ... MODIFY
- カラム変更ALTER TABLE ... CHANGE
- カラム名と型変更ALTER TABLE ... DROP
- カラム削除
テーブル削除
DROP TABLE
- テーブル完全削除
データ操作
SELECT
- データ取得WHERE
- 条件指定INSERT INTO
- データ挿入
実践での注意点(浩三さんより)
- 権限管理: 本番環境では適切な権限設定が必要
- バックアップ: 変更前には必ずバックアップを取る
- メンテナンス時間: ALTER TABLEは適切な時間に実行
- データ型選択: CHARよりVARCHARが適している場合が多い
- インデックス: パフォーマンスのために適切なインデックスを設定
- バリデーション: データ挿入前の検証が重要
今後学ぶべきトピック
- JOIN操作
- インデックス設計
- トランザクション
- ストアドプロシージャ
- パフォーマンスチューニング
- セキュリティ対策