命名規則

名前は一番安いドキュメント

ここからは物理設計に入ります。論理設計で決めた構造を、実際のデータベースで動く形に落とす工程です。最初に決めるのが名前です。

名前は、コメントや設計書と違って必ず読まれます。SQL を書く人は毎回テーブル名と列名を目にするからです。そして名前が揃っていないデータベースでは、書くたびに「この表はどっちの書き方だったか」を思い出す手間がかかります。1回あたりは数秒でも、それが何百回も積み上がります。

決める規則

このコースでは次の規則を採ります。PostgreSQL の世界で最も広く使われている形です。

対象規則
テーブル名小文字の snake_case、複数形order_items
列名小文字の snake_case、単数形unit_price
主キーidid
外部キー<参照先の単数形>_idstore_id
真偽値is_ または has_ で始めるis_active
日付_on、日時は _atordered_on / created_at

テーブルは複数形、列は単数形

迷いやすいのがここです。理由を持っておくと揺れません。

テーブルは行の集まりなので複数形です。stores は店舗の集まりです。一方、列はその行1件の1つの属性なので単数形です。stores.name は、その店舗1件の名前です。

SELECT name FROM stores と読んだとき、「店舗たちの中から名前を取る」と自然に読めます。規則が意味と一致していると、覚えるものが減ります。

大文字を混ぜない

PostgreSQL は、引用符で囲まない識別子をすべて小文字に畳みます。

CREATE TABLE "ProductMaster" (...); SELECT * FROM ProductMaster; -- productmaster を探しに行って失敗する SELECT * FROM "ProductMaster"; -- 引用符が必須になる

大文字を含む名前で作ると、以降ずっと引用符を書き続けることになります。書き忘れた瞬間にエラーになるので、事故の温床です。最初から小文字だけで作れば、この問題は起きません。

略語で削らない

cust_nmord_dt のような短縮は、打鍵を数文字減らす代わりに、読む人全員に解読を強います。補完が効く時代に短くする価値はほとんどありません。書く回数より読まれる回数のほうが多いので、読みやすさを優先します。

手を動かす

規則から外れた名前のテーブルを、ALTER TABLE ... RENAME で直します。

テーブル構造

CREATE TABLE "Product" ( "ProductID" integer PRIMARY KEY, "ProductName" text NOT NULL, "Price" integer NOT NULL ); CREATE TABLE "OrderTbl" ( "OrderID" integer PRIMARY KEY, "ShopID" integer NOT NULL, "OrderDate" date NOT NULL ); INSERT INTO "Product" VALUES (1, 'ノートPC', 128000), (2, 'マウス', 3200); INSERT INTO "OrderTbl" VALUES (1, 1, DATE '2026-04-01'), (2, 2, DATE '2026-04-02');

期待される出力

table_namecolumn_name
ordersid
ordersstore_id
ordersordered_on
productsid
productsname
productsprice

ヒント

query.sql
学習モード
コードの実行結果
データベースを初期化中...