テーブルのカラム名に迷ったんで、英語圏で仕事しているエンジニアに聞いてみた

テーブル設計をしていて、テーブル名やカラム名を付ける時、英語辞書を参考にするだけでは解決できなくて、様々なサイトを調べながらハチャメチャに悩みつつ「これは英文法的に正しいのか・・・？」と疑問に思いながらも、プロジェクトを進める場面が多いかと思います。

と言う事で、せっかく英語を勉強しているので、テーブルのカラム名を付ける時に判断に悩んだ事を、スペインでエンジニアをやっている友人に聞いてみました。
（仕事は英語でやっていて、以前はオーストラリアに住んでいた）

ちなみに、
「ググったけど、いろいろな言い方があるみたいで、結局どれを採用していいのか分かんねーよ！」
というものを主に取り上げています。
「表現方法はいろいろあるけど、システムで使うならこれ」
というのを書いている感じです。

また、変数名や関数名については、すごい議論が活発で、色々な情報が溢れていますが、テーブル名やカラム名については、そこまで議論が活発でないような気がします。

変数名や関数名は、基幹部分でなければ影響範囲を限定的する事が出来ますし、変更する時は IDEなり grep置換なりで一発変更は容易ですが、テーブル名やカラム名の場合、それだけでは上手く行かないケースが多んじゃないかと思います。

例えば、他のメンバーが既にがっつり作り込んでいたり、バックグラウンドで動くバッチ等が既にゴリゴリ書かれていたりするケースですね。

なので、テーブル設計をする時は、カラム名１つ１つに対しても、それが本当に扱いたいデータの実態に沿ってるのか、納得いくまで考えるべきだと思っています。

「細かい事は後で考えるとして、今はテキトーに作っておこう」と考えて安直に作ってしまうと、簡単に変更できないという側面があり、「後で考える」という段階が永遠に訪れる事がなく、考えついたとしても影響範囲を考慮すると修正は非現実的となり、テキトーな設計のまま本番リリースを迎え、歪な設計で開発者に大きな負担が発生したまま技術負債として残り続け、何年も稼働し続ける危険性は十分にあるのではないでしょうか。

というか、データベース設計をいい加減に進めてしまうと、大体そんな感じになるのではないでしょうか。

そういうワケで、データベース設計はプロダクトの開発段階だけでなく、その後の運用保守にも大きな影響のある、極めて重要なフェーズだと思っています。
個人的見解としては、気を回し過ぎるくらい十分に考え尽くすのが丁度いいと思っています。
このエントリが、少しでもその一助になればと思っています。

並び順

sort_order

order by で並べた時に、開発者の意図通りの順番で表示されるように設けるカラム名。
「pos」という表現もあるらしいが、「sort_order」が広く使われているそうな。

備考（特記事項的な意味合いのカラム）

note （他には remark, description, comment といった表現がある）

ちなみに「memo（メモ）」というのは、日本語らしい。
知らなかったぜえええーー

縦・横・高さ（奥行き・幅・高さ）

height, width, length

「height, width, depth」という表現もあるが、公式の時には、縦は ”L” と略されるので、lengthの方が使われる率が高いらしい。

変換前 / 変換後

target / converted

「一定のルールの基に、ある変換する」という事を扱うテーブルがあって、「変換前」「変換後」の内容を DBに保持する場合。
この表現が一番自然らしい。
“target_value” といったように、「value」といった表現は無くても十分伝わるそうな。

○○回数（「購入回数」など）

num_XXXX / number_XXX / number_of_XXX
「購入回数」なら、「num_purchases」や「number_of_purchases」

「number_of_purchases」でも文法的に問題はないが、「num」と省略する事も多いらしい。
（「num」は、省略記法としてはごく一般的で、請求書にも記載されるそうな）

日本人なら、つい「何とかカウント（XXX_count）」という表現を使いたくなるが、「count」は『数えていって、必ずゼロ（初期値）に戻るもの』という意味合いがあるため、「数量」や「回数」を表すには不向きとのこと。

また、カラム名は「of」を省略する事も多いらしい。

注意点としては、以下の２つは、受け取り方が全く違ってしまう。
num_purchases
num_purchase

前者は誰が見ても「購入回数」だが、後者は「購入したときに送られてくるコード番号」と勘違いされる可能性があるらしい。

省略して変な誤解が発生してまうよりも、長くなっても誤解がない表現の方がいいと思いますので、「number_of_XXX」が良いのではないでしょうか。

同じ思想でそうなったのかは知りませんが、MONICAでは、「number_of_XXX」というカラム名は、様々な箇所で使われています。

〜を使うか（例：「ヘッダを使うか」）

is_enabled_XXX / is_XXX_enabled

「ヘッダを使うか」なら「is_enabled_header」または「is_header_enabled」

上記の例は、
「CSVファイルの扱い方を扱うテーブルがあり、ファイルごとに扱い方を変える必要があって、その定義をDBに保持している。対象のファイルが、ヘッダあり/なし　かを判断するために使用するカラム」
という場面です。

「use_header」でも分からない事はないが、カラムを作る場合、「どんな値が格納されているか、予測しやすい名前にした方がいい」とのこと。
「is」で開始すると、「真偽値が入っているんだな」という事が名前を見ただけですぐに分かるので、なるべくそういう設計にする方がベター。
「is_active_XXX（is_active_XXX）」という表現もあるが、「is_enabled_XXX（is_XXX_enabled）」の方がよく見るらしい。

某所で「先頭が “is” のカラム名は不自然では？（変数名ならまだしも）」と指摘されたが、そんな事はないぞ。
と言う事で、先頭が “is” で開始するカラムを持つオープンソースのごく一部。（リンク先は、該当のカラムが分かる位置にしています）

Redmine
monica
koel

そういえば、Laravel で自動生成できるユーザテーブルにも「is_admin」というカラムがありますね。

is_XXX_enabled と is_enabled_XXX は、どちらも大きな意味の差はないみたいなので、どちらでも良意味たいですが、今回は「is_enabled_XXX」を採用しました。

複数のカラムが並んだ時、そっちの方が見通しが良かったので。

is_enabled_header
is_enabled_api_service_provider
is_enabled_job_scheduler

こんな感じで。

有効設定（有効かどうか）

is_enabled

コンフィグ情報などを扱うテーブルで、有効 or 無効の設定を ON/OFF に切り替える場面とか。

担当者

person_in_charge

「staff」だと、単に「オフィスにいる人」といったイメージになり、「関わっている人」という意味合いが無いらしい。
他には、supervisor / supervisor_name といった表現があるが、こちらは「責任者」と意味合いが強くなるそうな。

単価

unit_price

賞味期限

flavor_expiration_date

消費期限

expiration_date

納品書

statement / delivery_statement

他にも色々な表現があるらしい。

bill
invoice
slip
delivery card（主にアメリカ）

最も使われるのは「statement」だそうな。
そして、配送で使う納品書なら「delivery_statement」

invoice は、「請求書」と混同しそう・・・というか、請求書を扱う時に、使い分けが難しくなってくるので、statement がいい気がする。

送料

shipping_fee

ググったら、postage、carriage といった単語も出てくるが、前者は税金っぽいイメージがあり、後者は「馬車での輸送？」みたいなイメージがあるらしい。

消費税

consumption_tax

他には、「sales tax」「VAT」という表現があり、前者は主にアメリカで、後者は主にヨーロッパで使われる。
ただ、同じ「消費税」という名称でも、日本のそれとは性質が大きく異なるので、「日本国内で使用する消費税」を扱いたい場合、財務省のサイトにて使用されている表現「consumption tax」がベストではないでしょうか。

bitFlyer（仮想通貨売買サービス）でも「consumption tax」という表現が使われていたので、こっちでよいのではないでしょうか。