命名規則のベストプラクティス

同じ「利用者の ID」が、あるテーブルでは user_id、別のテーブルでは userId、さらに別のところでは uid と書かれている。JOIN を書くたびに定義を確認しに行く数十秒が、チームの人数ぶん毎日積み上がります。

どちらが正しいかではなく、そろっていない

命名の話は「複数形にすべきか」「is_ を付けるべきか」で止まりがちですが、現場で実際に困るのはそこではありません。困るのは混ざっていることです。users と order_item が同じスキーマに並んでいると、テーブル名を書くたびに単数か複数かを思い出す必要が出ます。どちらの流儀でも、全部そろっていれば思い出す必要はありません。

決め方そのものに正解はありません。決めたら全部そろえる。これだけが本質です。迷うなら、使っているフレームワークや ORM の既定に寄せておくと、ライブラリ側の想定と衝突しません。

混ざったスキーマを、1 つの流儀に寄せる

書き方が混ざった定義です。

テーブル名は単数、列名は大文字始まりと小文字始まりが混在し、RegDate と Flg は書いた人以外に読めません。ここでは「テーブルは複数形、語はすべて小文字で下線区切り」と決めた場合の姿を出します。

テーブル名に customer が入っているので、列を customer_name にする必要はありません。customers.name で十分に伝わります。

中身を言っていない名前と、予約語を置かない

避けたいのは data info flag value のような、何が入っているか言っていない名前です。作った直後は分かっていても、3 か月後に開くと中身を見ないと判断できません。is_active なら真偽値、registered_at なら日時だと名前だけで読めます。型と意味が名前から読めるかどうかが、そろえるときの実際の基準になります。

もう 1 つ、予約語は避けます。order user group key は使いたくなりますが、SQL の構文語と衝突します。

orders にしておけば、この面倒は最初から発生しません。

解説

名前は本番に出た瞬間、改名のコストが跳ね上がります。アプリのコード、バッチ、BI のクエリ、ダッシュボードまで追いかけることになるので、テーブルを作る前の 5 分がいちばん安く直せるタイミングです。