SQL の 基本 CREATEでデータベースの準備を！

この記事でできること（CREATE/DROPの全体像）

この記事では、SQLのDDLのうち CREATE（作成） と DROP（削除） を使って、データベースとテーブルを用意し、不要になったら削除するまでの流れを「最小手順」で整理します。

ここで“箱（入れ物）”を作れるようになると、次のINSERT/UPDATE/DELETEが一気に理解しやすくなります。

CREATE/DROPは、SQL学習の中でも「地味だけど重要」な土台です。

なぜなら、検索（SELECT）や更新（INSERT/UPDATE/DELETE）をどれだけ理解していても、そもそも 操作対象のテーブルが存在しない と始められないからです。

逆に言うと、CREATEで正しく“箱”を用意できれば、後の学習は「この箱に何を入れるか」「どう取り出すか」に集中できます。

また、CREATE TABLEの理解は「テーブル設計（どんな列を持つか）」の入口でもあります。

最初は完璧な設計を目指さず、最小で作る→動かす→必要に応じて直す という順番でOKです。

この記事は、その最初の一歩として「まず形にできる」状態を目指します。

さらに、CREATE/DROPは「環境差」にぶつかりやすい分野でもあります。

例えば、同じSQLでもDB製品やツールによって、エラー文の出方、確認のやり方、実行権限の持ち方が異なります。

ここでは“違いがあること”を前提にして、どの環境でも通用する考え方（確認→実行→再確認）を軸に説明します。

加えて、CREATE/DROPは“戻しづらい操作”が含まれる点がポイントです。

CREATEは基本的に安全ですが、DROPは誤るとデータや構造を消してしまいます。

この記事では、単に構文を覚えるだけでなく、事故を減らすための見方（対象確認・影響範囲の意識） も一緒に身につけます。

このページの位置づけ（DDLの入口）と学べる範囲

CREATEは「入れ物を作る」、DROPは「入れ物を消す」ための命令です。

データを検索するSELECT系や、データを追加・更新する更新系（INSERT/UPDATE/DELETE）より前に、まずは作業台を整えるイメージで押さえます。

このページで扱う範囲は次の3つです。

• CREATE DATABASE：テーブルを置く“データベース（箱）”を用意する
• CREATE TABLE：データを入れる“表（テーブル）”を定義する（型・制約の考え方まで）
• DROP：不要な箱を消す（ただし戻せない前提で安全に扱う）

一方で、環境ごとの詳細（GUI操作、権限付与、バックアップの具体的手順、製品固有のオプションなど）は、この記事では深追いしません。

まずは「共通する基本形」と「考え方」を固めて、必要になった段階で自分のDB製品の仕様に合わせて調整する流れにします。

「このページを読み終えたら何ができるか」を具体的にすると、

• テスト用のDB/テーブルを作って学習を回せる
• テーブルに必要な列と型を言語化できる
• DROPを安全に扱うための確認ポイントが分かる

という状態を目指します。

先に結論：よく使う最小構文（CREATE DATABASE / CREATE TABLE / DROP）

まずは“形”だけ覚えると迷いが減ります。

細部（権限・製品差・オプション）は後で追いかければOKです。

ここで紹介するのは、どのDBでも概ね通じる「最小の書き方」です。

自分の環境で実行する際は、

• 文末の;が必要か
• 大文字/小文字の扱い
• 予約語（使ってはいけない名前）がないか

といった“環境ルール”だけ軽く確認しておくと詰まりにくくなります。

また、学習をスムーズにするコツは「書く→実行→結果を読む」の往復を短くすることです。

エラーが出たら落ち込むのではなく、むしろ“答えが返ってきた”と捉えると上達が早くなります。

• データベース作成：CREATE DATABASE データベース名;
• テーブル作成：CREATE TABLE テーブル名 ( カラム名 型, ... );
• 削除：DROP DATABASE データベース名; / DROP TABLE テーブル名;

「CREATEで作る→（必要なら）DROPで片付ける」という往復ができると、学習の試行回数が増やせます。

結果として、INSERT/UPDATE/DELETEやJOINなどの理解も、実際に手を動かしながら進めやすくなります。

事前に押さえる用語（1分で）

この章では、以降の説明で何度も出てくる単語を短くそろえます。

ここが曖昧だと、CREATEの説明が「何を作っているのか」分からなくなりがちです。

データベース・テーブル・カラムの違い

• データベース：テーブルなどをまとめて入れておく“入れ物（フォルダ）”。
• テーブル：行と列でデータを並べる“表”。
• カラム（列）：表の列。

データ型や制約（ルール）を持つ。

ここで大事なのは「データベースの中にテーブルがあり、テーブルの中にカラムがある」という階層です。

階層が頭に入ると、操作対象（何を作るのか、何を消すのか）を見失いにくくなります。

もう一歩だけ具体化すると、次のように考えると理解が安定します。

• データベース：プロジェクト単位の“置き場”（アプリ用DB、検証用DBなど）
• テーブル：用途別の“表”（ユーザー表、注文表など）
• カラム：表の“項目”（ユーザー名、メール、作成日など）

というイメージを持つと、CREATE/DROPの対象を取り違えにくくなります。

DDLとは何か（CREATE/DROPが属する分類）

SQLは用途で大きく分類できます。

CREATE/DROPは DDL（Data Definition Language） と呼ばれ、データそのものではなく「構造（入れ物）」を定義・変更するための命令です。

DDLを理解するポイントは、「データ（中身）ではなく器（形）を扱う」という視点です。

器を変えると、入れられるデータの種類やルール（制約）が変わり、後からの運用や保守に影響します。

DDL以外もざっくり触れると、

• DML：データを操作する（INSERT/UPDATE/DELETE）
• DQL：データを問い合わせる（SELECT）

という分け方もあります。

全部を覚える必要はありませんが、「今やっているのは器の操作か、中身の操作か」を意識するだけで迷いが減ります。

実行前の準備（環境差を吸収する考え方）

CREATE/DROPは、使っているDB製品やツール（GUI/CLI）によって、確認方法や補助的なコマンドが変わります。

ここでは“差が出る部分”を前提にして、迷わない進め方だけを押さえます。

どこでSQLを実行するか（DB製品/ツールで違う点）

同じSQLでも、実行先（例：MySQL、PostgreSQL、SQLite、Oracleなど）や、実行環境（例：管理ツール、アプリ、コンソール）で挙動や補助機能が違うことがあります。

この記事では「基本形」を中心にし、細かな差は“自分の環境のドキュメントで確認する”方針で進めます。

最初におすすめなのは、次の2点を自分の環境で確認しておくことです。

• 今どのDB（接続先）に向いているか
• “一覧を見る/定義を見る”機能がどこにあるか

この2点が分かっているだけで、CREATEの成功確認と、DROPの誤爆防止がぐっと楽になります。

加えて、学習用におすすめなのは「検証専用のDB（またはスキーマ）」を作っておくことです。

学習で作るテーブルは増えがちなので、置き場を分けておくと混乱が減ります。

安全のための基本方針（本番と検証で扱いを分ける）

DROPは取り消しが難しい操作です。

学習や検証では気軽にDROPしがちですが、本番環境では大事故に直結します。

• 検証：作り直しやすさ優先（ただし削除対象は必ず確認）
• 本番：削除は極力避ける／バックアップやエクスポートの手順を先に用意する

「削除の前に確認」を習慣にするために、実行前チェックの型を決めておくと安全です。

• 対象名（DB名/テーブル名）を声に出して読む
• 一覧で同名が複数ないか確認する
• “今いる接続先”が想定どおりか確認する

安全の型をもう少しだけ具体化すると、DROP前に「影響範囲」を一言で説明できる状態にしてから実行するとミスが減ります。

• これは“テーブルだけ”を消すのか
• それとも“DBごと（箱ごと）”消すのか

CREATE DATABASE：データベースを作る

この章では、テーブルを置くための「入れ物（データベース）」を作ります。

テーブルだけを作る前に、まずデータベースという箱の存在を意識できるようにします。

基本構文（最小形）と意味

データベース作成の基本形は次のとおりです。

CREATE DATABASE データベース名;

データベース名 は自分で決めます。

英数字とアンダースコアなど、環境のルールに沿って命名します。

命名は「短く、意味が伝わる」ほど後で助かります（例：app_db、test_dbなど）。

環境によっては、文字コードや照合順序（collation）など追加指定ができますが、学習初期はまず最小形で問題ありません。

必要になったときに、使っているDBの推奨設定に寄せる形で理解すれば十分です。

作成時にありがちな注意点（名前・権限・既存有無）

CREATE DATABASEがうまくいかないときは、次を疑います。

• 名前のルール：使えない文字が混ざっていないか
• 権限不足：DB作成権限がないユーザーで実行していないか
• 同名が既にある：既に作成済みで失敗していないか

このあたりは、エラー文にそのままヒントが出ることも多いです。

慣れないうちは、エラー文を丸ごとコピーして読み返し、「何がダメと言われているか」だけ拾う意識でOKです。

また、学習中は「同名のDBを何度も作ろうとして失敗する」もありがちです。

慣れるまでは、作業するDB名を固定しておき、一覧で存在を確認してから次に進むと安定します。

作成できたかの確認方法（確認の考え方）

確認方法は環境差が出ますが、考え方は共通です。

• “一覧を見る”機能でデータベース名を確認する
• 管理ツールならツリー表示に追加されたか確認する
• 以降の操作（テーブル作成）がそのデータベース上でできるかで確認する

もし「作れたはずなのに見えない」場合は、接続先が違う（別サーバー/別環境）ことが原因になりがちです。

先に接続先を確認してから、もう一度一覧を見る癖をつけます。

CREATE TABLE：テーブルを作る（最重要）

この章がこの記事の中心です。

データを入れる前に「どんな列を持つ表にするか」を決め、CREATE TABLEで実際にテーブルを作れる状態にします。

まずはテンプレ：CREATE TABLEの最小ひな形

最小形は次のとおりです。

CREATE TABLE テーブル名 (
  カラム名1 型,
  カラム名2 型
);

( ... ) の中に列（カラム）を並べていきます。

列ごとに データ型 と、必要なら 制約（ルール） を付けます。

最初のうちは、列数を増やしすぎないのがコツです。

列が多いほど、型や制約の設計が難しくなり、エラー原因も増えます。

まずは2〜4列くらいで“作れる”体験を優先します。

もう1つのコツは、列名を「意味が伝わる英単語」に寄せることです。

後でSELECTを書くときに、列名がそのまま“説明文”になるため、SQLが読みやすくなります。

カラム設計の例（最小サンプルテーブルを作る）

例として、ユーザーを管理する最小テーブルを作るイメージです。

CREATE TABLE users (
  id INTEGER,
  name VARCHAR(50),
  birthday DATE
);

この例では、id を数値、name を文字列、birthday を日付として扱います。

まずは“列の種類を分ける”感覚を掴むのが目的です。

この時点では、まだ「idが重複していいのか」「nameは必須なのか」などのルールは決めていません。

次の“制約”で、テーブルのルールを固めていきます。

もう1つだけ、別の例も見ておくと応用が効きます。

例えば“商品”なら、

CREATE TABLE products (
  id INTEGER,
  title VARCHAR(100),
  price INTEGER
);

のように「ID」「名前」「数値（価格）」の組み合わせがよく出ます。

題材が変わっても、型の選び方は同じです。

データ型の選び分け（最低限）

データ型は「何を入れる列か」をDBに伝えるために重要です。

最低限、次のように覚えると迷いが減ります。

• CHAR(n)：固定長の文字列。
• VARCHAR(n)：可変長の文字列。
• INTEGER：整数。
• DATE：日付。

型選びで悩んだら、「その列に入る値の例」を3〜5個思い浮かべてみると決めやすいです。

例えば、name列なら「山田太郎」「Alice」「長めの氏名」などを想像して、最大長の目安をつけます。

さらに、型は“後から変えると影響が大きい”ことがあります。

最初から完璧にしなくても良いですが、

• 文字列に数値を入れない
• 日付は日付として持つ

など、データの意味に沿った型を選ぶ意識は早めに持っておくと、将来の集計や検索が楽になります。

制約の使い分け（最低限）

制約は「入ってくるデータのルール」を決めるものです。

データが増えてから後悔しやすいので、最初に最低限を押さえておくと安全です。

• PRIMARY KEY：行を一意に識別する（同じ値が入らない・基本的にNULL不可）
• NOT NULL：必ず値が必要（空欄を許さない）
• UNIQUE：同じ値を重複させない
• CHECK：条件を満たす値だけ許可する

制約は“面倒な縛り”ではなく、将来のミスを減らすための保険です。

特に主キー（PRIMARY KEY）は、後から付けようとすると手間が増えることが多いので、早めに決めるのがおすすめです。

また、制約は「守らせたいルールをDBに任せる」手段でもあります。

アプリ側の実装ミスや、人間の手入力ミスがあっても、DB側で止められるようになるため、データの品質が上がります。

例で理解する：PRIMARY KEY / NOT NULL / UNIQUE / CHECK の付け方

制約を付けると、テーブルの“品質”が上がります。

例を見ながら、何のために付けるのかを理解します。

CREATE TABLE users (
  id INTEGER PRIMARY KEY,
  name VARCHAR(50) NOT NULL,
  email VARCHAR(255) UNIQUE,
  age INTEGER CHECK (age >= 0)
);

• id：主キー。
• name：必須項目にしたいのでNOT NULL。
• email：メールアドレスは重複させたくないのでUNIQUE。
• age：負の年齢が入らないようCHECK。

このように、制約は「どんなデータを許可し、どんなデータを拒否するか」を明確にします。

拒否されるとエラーになりますが、それは“壊れたデータが入らなかった”という意味でもあります。

慣れてきたら、「この列は必須か？」「この列は重複してよいか？」を自分に問いながら、必要最小限の制約だけ追加していくのが現実的です。

制約を増やしすぎると運用が苦しくなることもあるため、目的（何を防ぎたいか）とセットで考えます。

ミニ実践：0から作ってデータを入れる前まで（流れで理解）

ここまでの内容を、作業の順番としてつなげます。

断片的な理解から「一連の作業」として理解に変えるための章です。

例1：DB作成 → テーブル作成（ここまでで“準備完了”）

最小の流れは次のイメージです。

1.

データベースを作る（必要な環境の場合）

2.

そのデータベース上でテーブルを作る

3.

テーブルの一覧や定義を確認して、意図どおりか確かめる

確認方法は環境差があるため、“一覧/定義を見る”手段を自分のツールで探しておくのがコツです。

ここでの狙いは「作ったつもり」をなくすことです。

CREATEは成功しても、作成先が違っていたり、別名で作っていたりして、後で迷子になります。

毎回、一覧で確認する流れにしておくと、学習中の混乱が激減します。

さらに、テーブルを作った後は「列名と型を一度読み返す」だけでも効果があります。

INSERTを書く前に定義を眺める癖がつくと、SQL全体のミスが減ります。

次に読むべきテーマ（INSERT/UPDATE/DELETEへの接続）

テーブルができたら、次はデータを操作します。

• データを入れる：INSERT
• データを更新する：UPDATE
• データを消す：DELETE

CREATE TABLEが理解できると、これらの命令が「どこに、何を、どう入れる/変える/消すか」に直結します。

更新系に進む前に、テーブル定義（列名・型・制約）を一度見直すのがおすすめです。

列名が曖昧だと、後でSQLが読みづらくなり、JOINを組むときにも迷いが出ます。

学習のつながりとしては、「CREATE→INSERT→SELECTで確認」を1セットとして回すのが特におすすめです。

目で結果を確認できるので、理解が早く固まります。

DROP：削除する（戻せない操作の扱い）

DROPは「構造そのものを消す」操作です。

学習中は便利ですが、実務では危険度が高いので、必ず“削除の前に確認する”習慣を作ります。

先に注意：DROPが危険な理由と回避策（バックアップ/エクスポートの考え方）

DROPを実行すると、テーブルやデータベースが消えます。

多くの場合、簡単には元に戻せません。

• 本番では、まずバックアップやエクスポート（退避）を検討する
• 削除対象の名前を、実行直前にもう一度確認する
• “削除する理由”が説明できない状態では実行しない

学習中でも、DROPを使うときは「削除対象を確認してから実行する」型を守るのがおすすめです。

慣れた頃に一番やりがちなのが“勢いで実行して別のテーブルを消す”事故だからです。

もう1つの注意点として、DROPは「トランザクションで戻せない／戻しにくい」ことがあります（DB製品や設定による）。

つまり、間違えた瞬間に取り返しがつかなくなる可能性があるので、必ず慎重に扱います。

DROP DATABASE：削除の基本構文と確認手順

基本形は次のとおりです。

DROP DATABASE データベース名;

手順の考え方はシンプルです。

1.

削除対象のデータベース名が正しいか確認

2.

実行

3.

一覧やツール表示で“消えたこと”を確認

データベースは“箱ごと”消えるため、影響範囲が大きい操作です。

削除前に「そのDBにテーブルが残っていないか」を確認する、という一手間を挟むだけでも事故は減らせます。

学習中は「テストDBだけを消す」運用にしておくと安心です。

実務でも、検証環境・ステージング環境・本番環境の区別が曖昧なときほど事故が起きるので、名前にtestを入れるなどの工夫も有効です。

DROP TABLE：削除の基本構文と確認手順

テーブル削除は次のとおりです。

DROP TABLE テーブル名;

こちらも同様に、実行前後で“対象が合っているか/消えたか”を確認します。

テーブルをDROPする理由としては、検証で作り直したい、命名や設計をやり直したい、誤って作ったので片付けたい、などが多いです。

迷ったら、まずはテーブル名を変えて新規作成し、古い方は“本当に不要”と確信してから削除するのが安全です。

また、他のテーブルが参照している（外部キーなど）場合、DROPが拒否されることがあります。

そういうときは「参照関係がある」というサインなので、影響範囲を再確認するきっかけにします。

よくある安全策（IF EXISTS相当・実行前チェックの考え方）

環境によっては「存在するときだけ削除する」書き方や、削除前に対象を確認する手段があります。

• 実行前に一覧や定義を確認してからDROPする
• “存在しないとエラーになる”状況を減らす書き方（環境の仕様に従う）

“存在するときだけ削除”の書き方は便利ですが、便利すぎて削除の危険性が薄れやすい点には注意します。

削除は常に「対象確認ありき」で扱うのが基本です。

よくあるエラー・落とし穴（初学者が詰まりやすい点）

CREATE/DROPは単純に見えて、ちょっとしたミスでつまずきやすい分野です。

ここでは“最初に見る場所”を固定して、復旧を早くします。

スペル/構文ミスで動かない（まず見るポイント）

• CREATE DATABASE / CREATE TABLE / DROP TABLE などのキーワードの綴り
• セミコロン;の付け忘れ（環境によって必須）
• カンマ,やカッコ()の閉じ忘れ

特に、カンマの付け忘れ/付けすぎはありがちです。

列定義は「列ごとに1行」にすると見落としが減ります。

また、予約語や記号が原因で失敗することもあります。

例えば、列名にorderなどの予約語を使ったり、スペースを含めたりすると、環境によってはエラーになります。

原因が分かりづらいときは「名前をシンプルにする」だけで解決することが多いです。

権限不足・接続先違い・対象DB違い

• 作成/削除の権限がないユーザーで実行していないか
• 接続しているDBが想定と違わないか（別環境・別サーバーなど）
• “今どのデータベースを操作しているか”を意識できているか

「自分は正しい場所で実行しているはず」という思い込みが一番危険です。

怪しいときは、接続情報や選択中のDB名を一度確認してから、もう一回CREATEを試す流れにします。

学習中でも、複数のDBを同時に触ると混乱しやすいです。

慣れるまでは「1つのDBに集中」し、別の題材に移るタイミングで片付け（DROP）をする、という手順にすると迷子になりません。

制約が原因で作れない/入れられない（原因の切り分け）

• PRIMARY KEY/UNIQUEで重複を許さない設計になっていないか
• NOT NULLなのに空欄を入れようとしていないか
• CHECK条件に反していないか

設計（制約）を強くすると安全性は上がりますが、エラーの原因が増えるので「どの制約に引っかかったのか」を読む癖をつけます。

エラーが出たら、まずは“どの列の、どの制約か”だけ拾うと原因に近づけます。

制約エラーは、言い換えると「ルール違反を止められた」状態です。

まずはルール（制約）を見直し、それでも正しいデータのはずなら、制約設計そのものが厳しすぎないかを検討します。

まとめ：CREATE/DROPで「箱」を整えると次が楽になる

最後に要点を短くまとめます。

この記事を読み返すときは、この章だけ見ても思い出せる状態を目指します。

本記事の要点3つ

• CREATEは“入れ物を作る”（データベース・テーブル）
• CREATE TABLEは、型と制約を決めるのが肝
• DROPは危険。

対象確認と退避の習慣が最優先

CREATE/DROPを一度経験しておくと、SQL全体の地図が見えてきます。

「器→中身→取り出し→片付け」という流れで覚えると、分野が変わっても応用しやすくなります。

最後に、学習用の簡単チェックリストです。

• CREATEしたら、必ず一覧/定義で確認する
• DROP前に、対象名と接続先を再確認する
• テーブル作成では、まず主キーと必須項目を意識する

次の学習導線（SQL基本の一覧・更新系・結合）

テーブルができたら、次はデータ操作（INSERT/UPDATE/DELETE）、テーブルが増えたら結合（JOIN）へ進むと理解がつながります。

学習を進めるときは、「テーブル定義（CREATE TABLE）を見て、INSERTを書く」→「SELECTで確認する」→「UPDATE/DELETEで変化を見る」という順番で手を動かすと、理解が積み上がりやすいです。

この流れを繰り返すほど、CREATE/DROPの意味も実感として定着します。

FAQ

最後に、初学者が混乱しやすい点をQ&Aで整理します。

ここを押さえると、CREATE/DROPと更新系の役割が混ざりにくくなります。

CREATEとINSERTの違いは？

CREATEは「テーブルなどの構造を作る」命令です。

INSERTは「そのテーブルにデータ（行）を入れる」命令です。

箱を作るのがCREATE、箱に中身を入れるのがINSERT、という違いです。

迷ったときは「データが増減する話ならINSERT/UPDATE/DELETE」「箱の形が変わる話ならCREATE/DROP」と区別すると整理できます。

テーブル設計で最初に決めるべきことは？

まずは「何を一意に識別するか（主キー）」と、「必須の項目は何か（NOT NULL）」から決めると、後で崩れにくくなります。

そのうえで、文字列の長さや日付など、データ型を現実に合わせて選びます。

もし迷ったら、最初は“仮”で作ってOKです。

作ってみてから「検索で困る」「重複が起きる」「空欄が多い」などの課題が見えてきた段階で、制約や列構成を調整するほうが、理解が早く深まります。

CREATEとALTERの違いは？

CREATEは“新しく作る”命令で、ALTERは“既にあるものを変更する”命令です。

学習初期は、まずCREATEで作れる状態を目指し、運用で変更が必要になったタイミングでALTERに進むと理解が自然につながります。

まずはCREATEで「箱を作れる」ことを確実にしてから、ALTERで「箱を直す」へ進むのが安全です。

DROPしてしまったら復旧できる？（一般論としての注意）

環境や運用によりますが、DROPは簡単には戻せない前提で扱うのが安全です。

復旧できる可能性があるのは、バックアップやスナップショット、ログなど“戻す仕組み”が事前に用意されている場合に限られます。

学習環境でも、念のため「消していいものだけが入っているDB/テーブル」を使う、というルールを作っておくと安心です。