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

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

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

カラムとフィールド

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

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

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

プログラム偏重の思考

プログラムベースで名前を付けることに違和感がない人達は、DB周りもプログラムと同じだとして捉えています。

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

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

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

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

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

どう考えるか

まずDBの値というのは静的で普遍的な物だという考え方が重要になります。

値が入ったり、情報が更新されることからこういったイメージを持てない人が多くいますが、DBのデータの方が重要でありサービスとしてはこちらの方が遥かに重要なのです。データを捨てることは出来ませんが、プログラムは捨てることの出来るものです。

他にも予約語被りです。

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つ目は市民権を得ているような単語です。

どこでも見かけるdelete_flagなど顕著ですが、市民権を得ている単語は固有名詞のような扱いになりやすいので、無理に名詞形にするよりそのままの方が分かりやすいです。

例えばdeleteやaddは名詞だとdeletionとadditionになりますが、後者の方が見慣れないです。

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

流行り物は考える

is_を使うことを催促してるものを見かけましたが、これはRuby on Rails（RoR）などの一部のフレームワークから来ている慣習であり、今の所これを促す公式な出典や標準規格は存在しません。

フレームワークなど何らかの強制が働く場合はそれに従えば良いのですが、そうでない場合に個人的におすすめしない理由は、複数の概念を混ぜると複雑度が増すためです。

どうしてもこれでやりたいのであれば真偽値で管理するようなデータでboolean型が存在するDB用です。

プログラム内で使われているbooleanを、DBとしてもそのままboolean型として登録しいる所で使われています。

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

海外のDBの構築でも状態フラグよりも属性フラグとして使用されることが多いです。

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

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

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

最終的な考え

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

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

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

既存プロジェクトに問題が有って、途中から命名を変更したいのであれば、自分が責任を持って全て修正する覚悟で取り組んで下さい。

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

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

あとがき

この記事を書くに至ったのは、当時関わっていたシステムはDBのカラム名をつける上で、割れ窓はあるものの大筋の流れがありました。

しかし、それを無視してプログラムの関数名や命名規約などの名称を、そのままDBのカラムにする泡沫ベンダーがいて、説得するのに困らせられた経験からです。

実際このベンダーはソースの名前や処理内容自体も意味不明な記述を連発しており、ゴミを作っただけで退場させることになりました。

ある程度まともな人は、ラバーダッキングをするとおかしな所に気づくのですが、コードについて積極的に考えようとしない開発者は、偶発的プログラミングを実践しています。

つまりコードが動作していても、何故そうしているのか、何故動いているかを説明できないのです。

偶発的プログラミングをしてしまう人は、コーディングという作業にもっと積極的な関心を持つべきなのです。