DBのカラム名は極力動詞を使わない方がいい

DBのカラム名は、その中にどんなデータが入っているかをイメージさせやすいような名称を付けるのが一般的です。

DBオブジェクトの中でもカラム名はパターンが多くなるため、単語に対してまでは命名規則を定めないため、割れ窓が存在しやすくなります。

DBのカラム名をつける上で、割れ窓はあるものの大筋の流れがあるにも関わらず、それを無視してプログラムの関数名や命名規約などの名称を、そのままDBのカラムにする人達がいて、説得するのに困らせられた経験があります。

カラムとフィールド

カラム名はフィールド名との相関性があり、ほぼ同じ名前になりますが、厳密には完全なイコールではありません。

フィールド名と同じにするにしても、ほとんどの場合、名詞、名詞句、または形容詞を使用してフィールドに名前を付けるはずです。

Microsoft 名前付けのガイドライン 型のメンバーの名前

プログラム偏重の思考

プログラムベースで名前を付けることに違和感がない人達は「プログラムから入って、DBは触る程度なので、プログラム偏重の思考」であり、DB周りもプログラムと同じだとして捉えています。

一部でフレームワーク自体が促しているものもあり、しょうがない部分もあると思いますが、プログラムベースでしか考えられないにしても、コードコンプリートくらい読んでおいた方が良いです。

DBA的な観点で、DB周りをガッツリ触ることを促している人の記事は、現代では消えて無くなっています。

現代社会の厄介な所で、本筋の内容はなく、関係ないブログや、参考元に書いてないガラクタ記事が大量に出てくるので、都合の良い部分だけ切り取りするためこういった現象になったようでした。

「プログラムの命名規約のブログ(参照元に記載されてない)」一時期よくあった「個人や会社がアピールするために書いている、参考にするには乏しいqiitaポエム」「国内でしか見かけないガラクタ命名規約」etc...

切り分けが非常に重要です。

本来どう考えるか

まず予約語と噛み合わないようにする事です。

SQLやコマンドは状態を変化させるための指示なので、予約語に割と動詞が含まれます。極力動詞を使わない方が被りは少なくなります。

前職のmysql環境でuse_xxxとか書いたなら、間違いなくパワハラを受けます。

作業時の記述ミスや、ライブラリやフレームワークのバグ、脆弱性を疲れた攻撃など、意図せぬSQLが走った場合に、顧客へのお詫びとデータの整合性まで含めて責任が取れて、かつ意味合いの整合性まで取れるのであれば否定はしませんが、使って明瞭になるケースの方が少ないです。

エドスティーブンス(DBA)の投稿にもありますがそもそも、ほとんどのデータ要素名は、名詞または形容詞 + 名詞のいずれかであることが多いです。

reference : Is there a non-syntactical guide for naming database columns? [closed]

他にも、よくある"user_role"という名前のカラムも、元は"user_has_role"という意味です。

どちらでもおかしくありませんが、一般的に動詞が省略されたものを利用しているはずです。

そうでないと、DB周り全てを文章で説明するような世界になっているはずですが、この世界線ではそうなってはいません。

横にならえで見れば、ほぼ名詞なので動詞や助動詞を採用しようと思わないはずです。

microsoft/sql-server-samples | AdventureWorks sample databases

おかしいかどうか判断できない場合は、エンティティ関係データモデリングでモデリングをすれば分かります。

例外的なケース

名前に動詞を使って分かりやすくなる少ない例として考えられるのが2つ。

1つは、2つのカラム間を説明するような第3のカラムが必要な場合です。テーブルだと、交差テーブルと内包テーブルが例としてあげられます。

2つ目は市民権を得ているような単語です。市民権を得ている単語は固有名詞のような扱いになりやすいです。

ゲームシステムなど、ゲームはキャラクターの動きに関連する情報や、非現実的な現象が普通にあるため、市民権を得ている名前にした方がわかりやすい場合があります。fly(動)とflight(名)など。

流行り物は考える事

is_を使うことを催促してるものを見かけましたが、これでやりたいのであれば真偽値で管理するようなデータでboolean型が存在するDB用です。

海外のDBの構築でも"is_active"\booleanの型で作られ、プログラム内で使われているbooleanを、そのままDB登録しているような所で使われています。

これが仮にプログラム内では0/1で利用していたとすると、カラムの内容を元に真偽値のメソッドを作成する際に、isIsActiveとかisXxxxIsActiveのような変な名前になってしまいます。

よくある最新の命名の間違いは、古典的な意味合いを理解していない人が携わってしまい、名前と整合しないデータや、曲解的な名前になったことから来ていることが本質的な問題で、流行りはそれに対するカウンターみたいなもです。

あらゆる物の名付けには教養が必要です。教養は一長一短には身につかないため、教養がない人ほどマジックワードに釣られます。

流行り物あるあるの、特定の名称だからだとか、フレームワークが簡単だからとかは、カーゴ・カルト的なベストプラクティス幻想です。

急に色気を出して、全体と違う名前を付けようとする人がいますが、アプローチに一貫性を持たせることの方がはるかに重要です。

最終的な考え

いかなる慣習も、必ずしも正しかったり間違っているというものは無く、すべてのソリューションに適合するようなものは有りません。

そして、命名を強制することは出来ませんが、間違った命名規則よりもさらに悪いことは、複数の命名規則が混在することです。

既存プロジェクトのデータベースオブジェクトに名前を付けるための、アプローチがすでにある場合は、それを使い続けてください。

命名規約が無い場合でも、割れ窓に注意して割れている方に靡かないようにして下さい。