はじめに
今までの経験で「読み解きがしんどい…」と思ったDB(テーブル)について記載します。
ER図をむりやりリバースで出して何となく推測したり、利用されている業務ロジックを紐解いて「あ、ここで使われているんだね」と泥臭く見ていけば理解できることはわかっています。
しかし、そんな泥臭さを得なくても理解しやすいテーブル設計にする方が、ゆくゆくメンテする人も開発に携わる人も、みんなハッピーになると信じています。
あとは、自分が同じことをしないためにメモっておく意味合いもあります。。
1. 論理名がない
例）gyunyu_detail_master_abc という名前のテーブルについて、説明なしのDDLとなっている。ぱっと見、何のテーブルなのか推測不可能。
物理名でテーブル説明を受けても、あまり頭に入ってこないです。
そのシステムへ長く携わる人からしたら、わかり切ったことだから物理名で話すのでしょう。
しかし、永遠に論理名のテーブルやカラム名で説明されるとしんどいです。
それが業務のコアな部分のテーブルだとなおしんどいです…
今後の教訓
DB設計するときは、面倒でも論理名をつける。
大切な業務を設計する場合は、必ず用語（と物理名）を定義する。
2. 用語揺れ
例）あるテーブルでは「milk」なのに、別のテーブルでは「gyunyu」と呼ばれている。
例のパターンだとまだ分かりやすいですが、専門知識を必要とする業務の場合、ぱっと見て「あ、これ同じなんだ」と分からないです。
また、例のように分かりやすい違いならいいのですが、微妙にスペルが違ったりしているといよいよしんどくなります。
例）gyunyuとgunuとmilk、みたいな。
過去に色々あったのでしょう。仕様を知らない人がスポットで入ってぱぱっと作ったのかもしれません。しかし、新参者の身としては、オロオロするしかないです…。
今後の教訓
用語（と論理名）を定義する。
3. マスタデータとトランザクションデータで、同じ意味合いのフィールド名が違う
例）マスタデータはgyunyu_idなのに、トランザクションデータはmilk_idとなっている
フィールドに限らず、テーブル名も微妙に命名パターンが異なると困ります。
作ったときに作業メンバーの仲が悪かったのかなぁと少し疑ってしまいます。。
今後の教訓
同一用語は同一論理名を使えるよう、用語を定義する。
4. マスタとトランザクションを紐づける項目が、IDではなく名称
例）牛乳マスタの値を注文テーブルに保持する時、IDではなく商品名「北海道xx牛乳」を持たせている。
何のためにIDが存在しているのだろうか…という気分になります。
これで2.や3.の症状を併発していると、ソースを深く深く根気強く読み解いて「あ、ここが繋がっているんだね」と気づく必要があります。
例のパターンでいうと、マスタの商品名が変更可能となってしまうと、紐付けを追いかけることができません。
トランザクションデータに断面的にマスタの情報を持ってくれていればいいのですが…持っておらずマスタデータを参照する必要がある場合、無理になります。
今後の教訓
一意かつ変化のないものを、リレーション関係として利用する
5. 謎の省略語
例）a_id、x_idなど
idであること以外、なにも分からないです。
これが業務のコアロジックに使われていて説明がないと…ほんとに何の話ってなりますね…😭
日本語の頭文字を取って「gn_id」みたいにしてくれていたらギリギリ推測がつくのですが（ダサいけど）。
今後の教訓
面倒に思ったとしても、フィールド名に適当な名前をつけない。
おしまい
しんどくなったことがあったら追記するかもしれないです。
最初に概念設計とかして用語の認識合わせるのは、本当に大事なんだなーとしみじみ感じます。