自分がDBのテーブル設計でこだわってる点がひとつあって、それはテーブル名の命名。なるべく1単語で表現する。 安易にusers_groupsとかつけてしまうとボディブローのように可読性が下がる。長くてもいいので一単語のものを必死で探す。 とくに問題になりやすいのが多対多の関係を保持する中間テーブル。 memberships, relationships, partnerships, sponsorships, mentorships, ownerships など、造語でもいいので関係性をあらわすものには -ships をつけてやると良いことが多い。 2カラムで外部キーだけを保持してるなら連結名でもいいけど、すぐにroleやjoined_atなどの独自のデータを保持したくなる。その瞬間から、自然な語彙になってない名前は一気に読みにくくなる。 カラムは規約である程度まで自動的に決まる（id, created_at, updated_atなど）のに比べて、テーブル名はドメイン知識がっつりだ。 コード中の変数名などはリファクタリングでガシガシと変えていけるが、DBに永続化された定義は変えにくい。プログラミングのなかで最も重要な「命名」というタスクのなかでも、最も慎重に決めたいのがDBのテーブル名。
今はAIに聞けば良い名前候補、将来破綻しにくい命名やテーブルの関係構造をバッチリ出してくれるのでいい時代になったんだ。 それまではDB設計や命名のセンスでメンテナンス性の高さに劇的な差がつくという世界だったんよ… 自分はけっこう語彙力で勝負できてたので差を縮められた側だと思う。
ちなみに、1単語ルールは変数や関数の命名でも有効。 3単語より2単語、2単語より1単語にすることで一気に見通しが良くなって本質的な理解が深まったりすることがある。 selectedItem, setSelectedItem ↓ item, setItem のほうが明らかに読みやすい。形容詞は疑え。