税率設計から学ぶDB設計、ちゃんと読んでみる

はじめに

あかねさんの記事「税率設計から学ぶ実務DB設計」を見て、勘がマジで鈍いのでどう自分ごととして持って帰ったらいいのか全然頭でわからなくて何回か読みました。

復習をそのまま書きます。茜さんの記事のなぞり書きでしかないので、個人的なノートだと思ってください。

まず「最悪の設計」から入る

なぜ茜さんの構成が優れているのかを知るためにまず、優れていないものをAIに聞きながら考えました。本当に何も考えずに見切り発車で考えるとこうなる↓

商品テーブル
- ID
- 商品名
- 価格
- 税率（10%とか） 

注文履歴テーブル
- ID

注文詳細テーブル（注文の際にどの商品を頼んだのか。1つの注文履歴に対して複数登録可能)
- ID
- 商品履歴ID（外部キー）
- 商品ID（外部キー）

これで何が困るかというと、

税率が変わったときに全商品を書き換えないといけない。しかも過去の注文データも書き変わるので「当時の税率」がわからなくなって以下みたいな人が出てくる。

「2年前に8%で買った注文なのに、今見たら10%になってる」

→ これはおかしい。明細が欲しくてAmazonの注文履歴を見に行った時に購入時と情報変わってたら困りますよね。

茜さんの設計

紹介されていたテーブルは4つ。

• TAX_RATES
  → 「いつからいつまで何%だったか」の履歴

• CATEGORY_TAX_CLASSIFICATIONS
  → 「このカテゴリはこの税区分」の対応表

• ORDER_TAX_LINES
  → 注文時の税率をそのままコピーして保存（カッコよくいうとスナップショット）
  → これがあるから税率が変わっても注文時のデータが維持できる

• AREAS
  → 海外対応のための地域一覧（地域ごとに税率が違うので必要)

茜さんの記事にあるDBをAIに図にしてもらいました↓

実際の買い物フローでDBの動きを追う

買う前（商品一覧の表示）

おにぎりの場合

1. PRODUCT_CATEGORY_IDを参照
   → 食品カテゴリだとわかる

2. CATEGORY_TAX_CLASSIFICATIONSを参照
   → tax_categoryはREDUCED（軽減）だとわかる

3. TAX_RATESを参照
   → effective_until = nullのレコード
   → 税率は8%だとわかる

4. おにぎり100円（商品テーブルがある前提） × 1.08 = 108円とわかる、UIに表示

この時点ではレコードは作られていません。ただ参照して計算するだけ。

買う瞬間（注文確定）

以下を一緒に買ったケースで考えてみます。

• おにぎり（カテゴリ：食品・消費税：8%）

• ボールペン（カテゴリ：文房具・消費税：10%）

ORDER_TAX_LINESテーブル（注文時の税率）
※1行目がおにぎり、2行目がボールペン

TAX_RATESテーブルから参照した税率をORDER_TAX_LINES（注文時の税情報を記録するテーブル）に保存する

買った後（履歴確認）

税金に関してはさっきのORDER_TAX_LINESだけ見ればOK。この時TAX_RATESはもう参照しなくて良い。

全体の参照フローの流れ

TAX_RATESは「今表示する税額を参照するのに必要な情報」
ORDER_TAX_LINESは「購入した時点での税金情報を参照するのに必要な情報」

疑問

1. product_category_idは不要では？（商品に直接tax_categoryを持たせちゃうのは?）

結論：正規化のために必要

これはシンプルな理由ですね。
商品テーブルに直接tax_categoryを持たせると、食品が1000商品あれば1000件全部tax_category: REDUCEDと書くことになっちゃいます。
↓こんな感じ

これだと同じ情報の繰り返しで正規化できていない状態。

↓茜さんの設計（カテゴリを経由する場合）はこう

⚪︎product（商品）テーブル
※実際は他にもカラムがあると思いますがシンプルにしています

⚪︎product_category（商品カテゴリ）テーブル

⚪︎CATEGORY_TAX_CLASSIFICATIONSテーブル

茜さんの設計だと、商品側が、product_category_id: 1（食品）を辿るだけで、おにぎり・サンドイッチ・お茶すべてがREDUCEDとわかるようになっている。

そのため、商品が1000件あっても CATEGORY_TAX_CLASSIFICATIONS テーブルにある食品カテゴリレコードのtax_categoryカラムを REDUCED or STANDARD に変えるだけで反映できるんです。

僕との比較↓

1. 僕の設計
   食品が1000商品あれば1000件全部tax_category: REDUCEDと書き直さないといけない

2. 茜さんの設計
   食品が1000件あっても書き直すのは食品カテゴリのtax_categoryカラム1件だけ

２の方が圧倒的に無駄がないわけです👍
正規化気持ち良い👍

2. CATEGORY_TAX_CLASSIFICATIONSテーブルのtax_overrideカラムっては不要では？

わざわざ本当は10%だよみたいな上書きをDBで持たなくてもTAX_RATES側で10%と8%のレコードを用意しておいて、会計計算時に10%の方を参照すればできるくねって考えました。

結論：インボイス制度の要件のため必要

まず、僕はお酒のような食品(8%)でありながら10%になるケースを考えました。

⚪︎元の設計（CATEGORY_TAX_CLASSIFICATIONS）

これをみて、税額が計算したいだけなtax_categoryカラム無くても、以下みたいにSTANDARDにしておけば10%って分かるからよくねって思いました（すみません本当)
↓こんな感じで。

⚪︎tax_overrideをなくした場合

ですが、問題発生。

なんと、国税庁のインボイス（適格請求書）の記載要件として「軽減税率の対象品目である旨」の明記が義務づけられてました。（？）
リンク：適格請求書等の記載事項

つまり、「計算上10%だが、軽減税率対象食品である」という事実をUIに表示しないといけないってことです。（なるほど)

なので、正確に軽減税率対象（REDUCED）であるかどうかをDBに残しておく必要があるわけです。

食品（お酒）カテゴリ
  tax_category: REDUCED  ← 「軽減税率対象かどうか」を判断するために必要
  tax_override: true     ← ただし酒類なので実際の税額計算は10%で行う

→ tax_overrideカラムはちゃんと必要でした。
→ 最初は何ならtax_categoryカラムも消せるんじゃないかとか超はやとちりしました

感想

ここまでを理解するだけで時間がとっっっっっっってもかかりましたが、テーブル設計の構成自体は純粋に原則（責務分離や正規化）に基づいて作られていました。

今回理解の難易度が上がった一因として、税という技術外の知識が求められた点があります。
なぜこの設計になっているかを読み解く上で、仕様理解が必須でした。
でも実際に現場でDBの設計にアプリの仕様を落とし込まないといけない時は,そもそも技術外の知識がいるってことがあります。
逆に言えば技術街の知識とか経験が力になるってことでもあります（キリッ）

設計の背景にある「なんで」を追ってしまったら最後、税金のことまで調べないといけなく本当に嫌でした。疲れた頭痛え。

あかねさんありがとうございました😇😇😇