非エンジニアのためのbubbleのデータベース命名規則

どうも、けいです(https://twitter.com/NoCoder_K)

今回の記事は、前回に引き続きデータベースに関するものです。まだ読んでない方はこちらをまずご覧ください。

前回の記事では、データベースをどうやって構築していけばいいか、という解説でしたが、今回はその設計を元に、「このように命名すると(名前を決めると)後から見ても分かりやすいよ」というルールみたいなものを解説します。

一見すると、そんなのどうでもいいよね？と思いがちですが、後からのメンテナンス性、また、今後誰かと共同で開発していく上で、共通認識でテーブル名、field名を定義することは非常に重要になってきます。

エンジニアでプログラミングの経験がある場合などは、一般常識として持たれてる方も多いですが、今回はそんなの考えたこともない！と、これまで適当にデータベースを作ってきた方向け非エンジニアのために解説していきます。

前回の記事では、あえてこの説明はせずに、そして今から紹介するルールは無視して構築していました。

それでは、始めます。

全般編

1.基本は英語

テーブル名、field名は基本的に英語(アルファベット)で定義します。日本語入力でもできるみたいですが、一般的なデータベースではアルファベットでの記述が原則です。

これは、プログラミングで”変数”となるものに対して「日本語」を設定できないのと同じですね。もっと分かりやすく言えば、数学で変数を用いるときに、「x=」「y=」「z=」などは使いますが、「あ=」「い=」「う=」とはしないのと同じだと認識しておきましょう。

また、英語にしておくことで、以前撮影したbubbleの作業スピードを爆速で早めるテクニックというYouTubeで紹介する方法も使いやすくなります。

2. 複合文字は「 _ 」(アンダーバー/アンダースコア)で繋ぐ

複合文字とは、例えば以下のものは命名規則としては優れていません。

・product name
・productname
・productName

このような名前を付けたい場合は、

product_name

とするようにします。

Table名編

ここは特にありません。上記の全般編を参考にしてください。

Field名編

1. リレーションは、そうであることを明確にする

リレーションの関係を持たせる時、そのfieldがリレーションなのかどうか、を明確にすると管理がしやすくなります。これはあまり他のデータベースの命名記事には見られないので、僕独自のルールという感じです。参考にするかどうかはご自身で判断ください。

具体的には、Reviewというテーブルに対して、”どのProductか？”というfieldをリレーションで繋ぐ場合は、単に「Product」とするのではなく、「which_product」として、まさに”どのProductか？”を分かりやすくしています。

2. フラグは「〜flg」としない

yes / no で定義するfieldは、フラグといった呼び方をします。その際、多くの場合は「〜flg」や「〜flag」のような命名になりがちなんですが、データベースは誰が見てもその役割が分かるようなものが好ましいので、これは避けた方が無難です。

では、どうすればいいのか？

例えば、売り切れの判定をするために「sold_flg」と名前を付けたとします。これだと、yesで売り切れなのか、noで売り切れなのか、少しだけ迷ってしまうことがあります(この例だとあまり迷わないですが笑)

なので、この場合は、「is_sold」とすることで、「が、売れた」と直感的に分かるので、yesの時は売り切れ。noの時は販売中とすぐに分かります。

話がそれますが、bubbleの場合は yes/ no と直感的に分かるので上記の例でもそれほど混乱しませんが、これが true/falseや on/offとなると「sold_flg」だけでは分かりづらくなるので、この際クセとして意識していけるようにしましょう。

コーディングされてる方と一緒に開発していくという流れが今後出てきた場合にもスムーズに共通言語として把握しやすくなります。

他の例でも、”削除してもいい”というフラグに対しては、「delete_flg」とするのではなく、「can_deleted」とすればより分かりやすく、他の人から見てもこれだけでyesなら”消すことができる”。と分かりますよね。

”発送した”などは「has_shipped」などにするといいかもしれません。

このように、テーブル名やfieldは意味のある命名を心がけましょう。多少長くなっても、文章のようになったとしても、この方がおすすめです。

正確には beがいるとか beenだろ〜とか言われそうですが、まあそこまでこだわる必要はないかと個人的には思います。

bubbleでは、テーブル名、field名に日本語が使えたり、スペースを含んだ複合文字が使えたりと、一般的なデータベースやプログラミングの変数ではありえないことができてしまうんですが、今後自分がプログラミングに挑戦しようとしたときや、プログラミングができる開発者と一緒に開発する流れがきたときにすぐに対応できるように、命名規則として習慣づけていきましょう。

それでは！