Skip to Content
Akiba No Baito Queenアキバのバイト女王 - MySQL編

アキバのバイト女王 - MySQL編

第一幕: 店長の突然のクイズ

📍 秋葉原のメイドカフェ🕐 午後 2:00
📝 語り手:

暇な午後、店長が突然私にニヤリと笑いかけた。浩三さんも隣で困った顔をしている。

店長 avatar

店長

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

私 avatar

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

店長 avatar

店長

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

私 avatar

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

浩三 avatar

浩三

あの、店長さん…

店長 avatar

店長

答えはこうだ!

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フィールドを定義
浩三 avatar

浩三

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

店長 avatar

店長

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

私 avatar

あの…全然わからないです…

第二幕: 次々と出される問題

📍 秋葉原のメイドカフェ🕐 午後 2:10
店長 avatar

店長

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

私 avatar

え…えーと…

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文字固定長のログメッセージを格納
浩三 avatar

浩三

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

店長 avatar

店長

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

私 avatar

DATE型とTIME型って違うんですね…

第三幕: テーブル変更の連続攻撃

📍 秋葉原のメイドカフェ🕐 午後 2:20
店長 avatar

店長

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

私 avatar

変更?!追加?!

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 で挿入位置を指定
浩三 avatar

浩三

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

店長 avatar

店長

浩三、うるさいな!

店長 avatar

店長

次!testテーブルのidのデータ型を8文字に変更する!

Input

ALTER TABLE test MODIFY id CHAR(8);

Output

テーブル 'test' が正常に変更されました。 - id: CHAR(8) に変更 (INTEGER → CHAR(8))

Explanation

既存カラムのデータ型を変更する操作。

  • MODIFY で既存カラムの型を変更
  • INTEGER から CHAR(8) に変更
  • データの互換性に注意が必要
浩三 avatar

浩三

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

店長 avatar

店長

浩三、黙ってろ!

私 avatar

えーと、データが変わっちゃうんですか?

第四幕: さらなる変更とプロの警告

📍 秋葉原のメイドカフェ🕐 午後 2:30
店長 avatar

店長

次だ!usrテーブルのunameのフィールド名をusernameに変更する、データ型は15文字とする!

Input

ALTER TABLE usr CHANGE uname username CHAR(15);

Output

テーブル 'usr' が正常に変更されました。 - uname → username に変更 - データ型: CHAR(15)

Explanation

カラム名とデータ型を同時に変更する操作。

  • CHANGE で既存カラムの名前と型を変更
  • uname から username に名前変更
  • 同時にデータ型も指定
浩三 avatar

浩三

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

店長 avatar

店長

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

店長 avatar

店長

次!usrテーブルのfamilyのフィールドを削除する!

Input

ALTER TABLE usr DROP family;

Output

テーブル 'usr' が正常に変更されました。 - family カラムが削除されました - データも完全に削除されました

Explanation

カラムを完全に削除する操作。

  • DROP でカラムを削除
  • カラムに含まれていたデータも全て削除される
  • 復元は不可能
浩三 avatar

浩三

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

店長 avatar

店長

浩三、もう黙ってろ!

私 avatar

あの…データが消えちゃうんですか?

第五幕: 恐怖のDROP TABLE

📍 秋葉原のメイドカフェ🕐 午後 2:40
店長 avatar

店長

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

私 avatar

削除?!

Input

DROP TABLE crash;

Output

テーブル 'crash' が完全に削除されました。 - テーブル構造とデータが全て削除 - 復元は不可能

Explanation

テーブル全体を削除する操作。

  • DROP TABLE でテーブルを完全に削除
  • 構造もデータも全て削除される
  • 最も危険なSQL操作の一つ
浩三 avatar

浩三

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

店長 avatar

店長

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

浩三 avatar

浩三

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

私 avatar

あの…私にはよくわからないですが、浩三さんが心配そうです…

第六幕: データを見るクエリ

📍 秋葉原のメイドカフェ🕐 午後 2:50
店長 avatar

店長

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

私 avatar

見るだけなら安全ですね…

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 でテーブルを指定
  • カンマ区切りで複数カラムを指定
浩三 avatar

浩三

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

店長 avatar

店長

そうだ!じゃあ条件付きの検索だ!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のレコードのみ抽出
  • 指定したカラムのみ表示
私 avatar

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

浩三 avatar

浩三

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

店長 avatar

店長

また始まった…

第七幕: データ追加で締めくくり

📍 秋葉原のメイドカフェ🕐 午後 3:00
店長 avatar

店長

最後だ!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 で実際の値を指定
浩三 avatar

浩三

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

店長 avatar

店長

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

私 avatar

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

店長 avatar

店長

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

浩三 avatar

浩三

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

私 avatar

なるほど…勉強用と実際の現場では違うんですね…

エピローグ: 学んだこと

📍 秋葉原のメイドカフェ🕐 午後 3:10
私 avatar

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

店長 avatar

店長

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

浩三 avatar

浩三

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

私 avatar

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

店長 avatar

店長

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

浩三 avatar

浩三

そうですね。基本を理解してから、実践的な部分を学んでいけばいいと思います。

📝 語り手:

こうして、私の初めての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 - データ挿入

実践での注意点(浩三さんより)

  1. 権限管理: 本番環境では適切な権限設定が必要
  2. バックアップ: 変更前には必ずバックアップを取る
  3. メンテナンス時間: ALTER TABLEは適切な時間に実行
  4. データ型選択: CHARよりVARCHARが適している場合が多い
  5. インデックス: パフォーマンスのために適切なインデックスを設定
  6. バリデーション: データ挿入前の検証が重要

今後学ぶべきトピック

  • JOIN操作
  • インデックス設計
  • トランザクション
  • ストアドプロシージャ
  • パフォーマンスチューニング
  • セキュリティ対策
Last updated on
Do not shoot this.