こう
- 「テーブル設計で、
正規化と 非正規化を どう 判断しますか」 - 「一覧の
画面が 遅いので、 集計した 値を 表に 持たせたいと 言われました。 どうしますか」 - 「注文の
状態が 変わった とき、 行を 上書きしますか」
面接官が
- 正規化の
用語の 説明ではなく、 ビジネスの 要る 物 (速さ、 正しさ、 あとで 調べられる こと) と 照らして 決められるか - 崩すときに
「測って 遅いと 分かったから」と 根拠を言えるか - 崩した
あとの 食い 違いを、 どう 防ぐかまで 考えているか - お金や
履歴の データは 消さずに 残す、という 感覚を 持っているか
短い答え
- 基本は
正規化して、 同じ 事実を 1 か所にだけ 置き、 重複と 食い 違いを 防ぎます。 - 読み取りが
とても 多く、 測って 性能が 足りないと 分かった 所だけ、 集計の 列や キャッシュで 非正規化します。 - 決済や
履歴の データは 上書きや 削除を せず、 状態が 変わる たびに 記録として 足していきます。
少し
まず正規化する理由
同じ値を
崩すのは
一覧の
SQL クエリ
-- 記事ごとのいいねの数を持つ
ALTER TABLE posts
ADD COLUMN like_count
INT NOT NULL DEFAULT 0;いいねを
集計の
決済や
注文の
SQL クエリ
-- 状態の変化を行として足す
CREATE TABLE order_events (
id BIGINT PRIMARY KEY,
order_id BIGINT NOT NULL,
status TEXT NOT NULL,
created_at TIMESTAMP
NOT NULL
);今の
トレードオフ
非正規化すると
よく
- 遅くなりそうだから、と
最初から崩す測る 前に 崩すと、 食い 違いのもとだけが増えます - 集計の
列を 足して、 更新を 別々に行う 片方だけ成功すると 数が ずれます。 同じ トランザクションに まとめます - 注文の
状態を 上書きする 過去の 経緯が 消え、 問い 合わせに 答えられなくなります
深掘りの問い
- 「集計の
列と 元の データが ずれたら」元の 表を 正として 数え直す処理を 用意し、 定期的に 照らし合わせる、と答えます - 「キャッシュと
集計の 列は、 どう 使い 分けますか」 少し 古くて よい 読み取りは キャッシュ、 正確さが 要り画面ごとに 使う値は 集計の 列、と答えます - 「消したい
データ (退会した 人の 情報) は どうしますか」 個人の 情報は 消すか 見えなくし、 お金の 記録は 法令や 会社の 決まりで 残す期間を 確かめる、と答えます