じゃあ、DROP TABLE コマンドでデータベースからテーブルを正しく削除する方法について話そう。
DROP TABLE は、テーブルのデータも構造もまるごとデータベースから消しちゃうコマンドだよ。例えば、卒業論文を書いて、うっかりノートPCごと燃やしちゃった感じ。これが DROP TABLE の威力。怖い？大丈夫、ちゃんと仕組みを理解して慎重に使えばOK！
DROP TABLE の特徴：
- テーブル全体（データも含めて）を復元できない形で削除する（バックアップしてなければね）。
- テーブルが使ってたディスク領域も完全に解放される。
- 関連するインデックス、制約、トリガーも全部消える。
DROP TABLE コマンドのシンタックス
DROP TABLE のシンタックスはめっちゃシンプル：
DROP TABLE テーブル名;
ここで：
テーブル名— 削除したいテーブルの名前。
テーブル削除のシンプルな例
例を見てみよう。例えば students というテーブルがあるとする：
CREATE TABLE students (
id SERIAL PRIMARY KEY,
name VARCHAR(100) NOT NULL,
age INTEGER CHECK (age > 0)
);
このテーブルがもういらないなら、次のコマンドで削除できる：
DROP TABLE students;
このコマンドを実行すると、students テーブルはデータベースから完全に消えるよ。中に入ってた学生データも全部消える。
複数テーブルの削除
1回のクエリで複数のテーブルも削除できる。カンマで区切って並べるだけ：
DROP TABLE table1, table2, table3;
例：
DROP TABLE students, teachers, courses;
このコマンドで students、teachers、courses の3つのテーブルが一気に消える。
IF EXISTS の使い方
DROP TABLE で 存在しないテーブル を消そうとするとエラーになる。これを避けるには IF EXISTS オプションを使おう：
DROP TABLE IF EXISTS テーブル名;
例：
DROP TABLE IF EXISTS students;
students テーブルがあれば削除されるし、なければエラーなしで警告だけ出る。
依存関係を考慮したテーブル削除
他のテーブルやオブジェクトが依存してると、テーブル削除が難しくなることがある。例えば、外部キーで他のテーブルとつながってる場合とか。外部キーについては次のレベルで詳しく話すね :P
例えば students と enrollments という2つのテーブルがあるとする。enrollments テーブルは外部キーで students に依存してる。
CREATE TABLE students (
id SERIAL PRIMARY KEY,
name VARCHAR(100) NOT NULL
);
CREATE TABLE enrollments (
id SERIAL PRIMARY KEY,
student_id INTEGER REFERENCES students(id), -- カラム student_id は students.id を参照
course_name VARCHAR(100)
);この状態で students テーブルを enrollments を消さずに削除しようとすると、こんなエラーが出る：
DROP TABLE students;
-- ERROR: テーブル "students" を削除できません。他のオブジェクトが依存しています
-- DETAIL: enrollments テーブルの enrollments_student_id_fkey 制約が students テーブルに依存しています
依存してるオブジェクトもまとめて消したいなら CASCADE オプションを使おう：
DROP TABLE students CASCADE;
このコマンドで students テーブルと、それに依存してるオブジェクト（この場合は enrollments テーブル）も自動的に削除される。
でも CASCADE の使いすぎには注意！思ったより多くのオブジェクトが消えることもあるから、何が消えるかログでちゃんと確認しよう :)
依存オブジェクトを消さずにテーブル削除を防ぐ
うっかり関連オブジェクトまで消しちゃうのを防ぎたいなら RESTRICT オプションを使おう。このオプションは、他に依存してるオブジェクトがあるとテーブル削除を禁止してくれる：
DROP TABLE students RESTRICT;
依存オブジェクトがある場合はエラーになって削除がキャンセルされる。
一時テーブルとその削除
一時テーブル（CREATE TEMP TABLE で作るやつ）は、データベースセッションが終わると自動的に消える。でも、セッション中に手動で DROP TABLE で消すこともできるよ。
例：
CREATE TEMP TABLE temp_data (
id SERIAL PRIMARY KEY,
value TEXT
);
DROP TABLE temp_data;DROP TABLE でよくあるミス
存在しないテーブルを消そうとする。 エラーを避けるには IF EXISTS を使おう。
DROP TABLE IF EXISTS non_existing_table;
依存関係があるのに CASCADE を使わずに削除しようとする。 他のテーブルが依存してるとエラーになる。全部消していいなら CASCADE を使おう。
DROP TABLE students CASCADE;
CASCADE の使いすぎ。 重要なオブジェクトまで消えることがあるから、何が消えるかちゃんと理解してから使おう。
うっかりテーブルを消しちゃう。 特に本番データベースでは、何を消すか2回は確認しよう。
ちょっと真面目な便利アドバイス
便利アドバイス1：全部否定しよう
データより先に証拠を消そう。
そして自信満々に「ログの異常でした。もう直しました」と言おう。
それが仕様だと言い張ろう。
「耐障害性のストレステストをやってみたんです…で、システムが落ちました。でも改善点が分かりました！」
「プロダクションレベルのインシデントです」と避難を宣言しよう。
みんながパニックになってる間は、誰も DELETE FROM を WHERE なしで実行した犯人を追及できない。
hh.ru で DBA 名義の履歴書を更新しよう。
これで本当にデータベースに近づいたね。特に、もう存在しないやつに。
コーヒーブレイクを事前に計画しよう。
数分後に「プロジェクトからしばらく休んで」って言われるかもだから。
ここは staging だったことにしよう。
「これテスト環境じゃなかったっけ？なんかテストしてた気がする…たぶん…」
オープンスペースのど真ん中に座ろう。
そんな堂々と座ってるやつが犯人なわけないって思われる。
ChatGPT のせいにしよう。
これ全部 AI のせい。まだ人間の代わりにはなれないって証明できた。クビにしないでね。
便利アドバイス2：やらかした後の転職活動
全部のテーブルを一気に消そう。そうすれば上司も忙しすぎて誰をクビにするか決められない。
一人で責任を取らない。上司も巻き込めば悪い評価はつかない。
顧客データまで消した？おめでとう、会社は君のクビどころじゃない大問題を抱えることになる。
便利アドバイス3：削除前にバックアップしよう
ここからは冗談抜きで。
テーブルを削除する前（特に大事なデータが入ってる場合）は、pg_dump コマンドでバックアップを取ろう。うっかり消しても復元できるからね。
バックアップコマンドの例：
pg_dump -U username -d database_name -t table_name > table_backup.sql
これで DROP TABLE の基本はバッチリ！この「核ボタン」は本当に必要な時だけ使おう。次のレクチャーではテーブルや他のデータベースオブジェクトの構造変更について続けていくよ。
GO TO FULL VERSION